Okay. I think we’re ready to go with our good lunch and a great keynote, a great keynote lecture. So now we have Lessons Learned: How to Review and
Improve Internally Built Applications. We have Jonathan Lee and Shawn McComb.
Take it away gentlemen. Okay. So first of all, I think there’s an
echo. I think this thing’s on. But The previous speakers were like “Eh… it’s hard to tell.” It really is hard to tell. Okay. So I guess we got the challenging time slot. You’re all half asleep from your amazing lunch. And we get to repeat things that you already potentially heard today and add little bit to it. So this really begins as a presentation that is a big THANK YOU. At Missouri State University, we’ve had the privilege while we’re working through our back catalogue of applications, to have some amazing partners here on campus. One of those amazing partners is our office of web strategy and development, which is represented at this conference. They work with us to understand how our applications react and behave in regards to what they’re putting out to the campus at large, and the community at large as far as our primary web pages. Our other huge partner in this process was our Disability Resource Center. We’ve learned an incredible amount through a partnership with that office. The beauty of having an office like that on campus is the fact that, we had users we had people from faculty staff, students who all care deeply about accessibility, partnering with us to understand what it’s like to use our applications. And that was a resource that many of you may not have, but was transformative for us. Who we are. So I’m Jonathan Lee. I’m the senior systems analyst here at Missouri State University over our DevOps team and our management information systems area, inside information services. So if that was super long, that’s where I live. Shawn is one of our programmers. He focuses a great deal on ADA concerns in his programming. We both have experience in higher education, software development, systems administration, and more. On a personal level, I got interested in this topic for a lot of personal reasons. If you were to see my family walk down the street, we would look like any other family. You would not know, necessarily, that my son is autistic. You wouldn’t necessarily know that my wife was injured as an adult, and became an epileptic. And we suddenly couldn’t watch a lot of movies. And we couldn’t go to Live Music Venues. You wouldn’t know, looking at my daughter, that she takes a cocktail of medications to be able to make her memory work at all. So we all looked very normal. And yet each one of us in my household, has disability concern. And that’s true of countless Americans that we interact with. People around the world that are our prospective students in higher education. And so oftentimes, the needs for these types of efforts and energies slide under the radar. Because it’s not obvious how big and how important the user base is for these issues. So I want to get a sense of who’s in the room a little bit. How many of you would consider yourself a software developer in some form or fashion? That’s a reasonably good chunk. How many of you work in QA processes for software development or UI UX work? Pretty decent number. How many of you work directly in Disability Services in your organization or in your institution? Okay. So unfortunately, you make up the minority of the crowd but an important and key component to the conversation. I don’t know if anybody here is willing to be interactive in this process. I’m a pretty interactive person when I present and when I interact in general at work. Is anybody willing to kind of throw out what it is they were hoping to get out of this conference, maybe this session? Something we could use as a touch point to sort of drive or steer some of our conversation? … … So what are the top things that we
should focus on first? Some of those tie together really well. The first question was really a question about you know how do we make sure our internal and external applications are really hitting best practices? Even beyond a legal standpoint. How do we even prioritize that? Because there’s an incredible amount to do. It seems like an overwhelming and daunting task. Certainly when Shawn and I began our project here at Missouri State University, terror might be the right word to describe the process. Because frankly we weren’t experts and still aren’t experts. And the most important thing I’m going to have you take away from this entire experience is none of you are either. And you won’t get there. It’s a journey, not a destination. So to a great degree, a part of this process is not thinking in terms of 508 compliance, not thinking in terms of WCAG 2.0 2.1 compliance, but really asking yourself, “How do we make amazing applications? How do we make amazing web services that are available to absolutely everybody?” And in doing so, we can use tools like WCAG, and we can use guidance from the government to understand what that should look like. But those are guideposts. Because many of you have read those specifications… they’re all over the map. And they give kind of a bit of guidance. They’ll give you a few examples. But the reality of the matter is, things don’t become accessible until the people that are using them can use them. Regardless of what metric you hit. Shawn.
Shawn: So we’ve learned a lot of things about this process. As I said, it’s very much a journey. We continue to learn new stuff every week. We get challenged to do new things every week. I spend a lot of my time right now looking at WCAG 2.1. Anybody looking at WCAG 2.1 in a serious way? Some of you are. It’s been out a year and a week. So 51 weeks right now. It brings forward some real challenges that are really hard to benchmark. They’re really hard to make… something that you can make objective to a great degree. Because really they deal with key issues like for instance, the concept of cognitive flow. So this presentation is going to talk a little bit about our technical toolkit that we use. We’re going to talk a little bit about the human factor involved in the process. And we’re gonna tie it all together. And since I know we have at least one person in the room who is unable to see the slides with us. I’m going to be the screen reader of each one of these slides. So we’re going into technical tools and solutions. And I put up an image of some loose tools to kind of represent that. I really don’t like PowerPoint. I know that PowerPoint is the gold standard for giving presentations. But as we’re discovering even in the conference like this, there are oftentimes people who don’t get the full benefit of PowerPoint because of what it represents, and who it’s tailored for.
radio buttons, you have a better choice. You have drop-downs and they work really
well on mobile applications on phones. The other big thing is… [noise] [noise] … [noise] … Radio buttons.
I don’t know how adept any of you are at playing video games. For those of you that grew up in a generation where playing video games was commonplace, radio buttons present no challenge to you whatsoever. They’re great. All you gotta do is click on the radio button. If you happen to have somebody who is trying to use an assistive pointing device, say for instance an alternative mouse, and you watch them struggle to select a radial button out of a list of radio buttons, you will understand their immediate frustration and hostility to them. Yes. Yes. Oh excellent. Brad gets to edit this out of the file with the recording later on so… No. Shawn’s going to have it here in a second. If only I was a better dancer, I could entertain you. Okay. So if you do choose radio buttons, and you really shouldn’t choose radio buttons, do not make a long list of them Do not try to have 7 plus options of radio buttons which legacy applications have. Admit that that’s really a drop-down. Admit that a radio button is a pain to cycle through with keyboard navigation. Because with keyboard navigation you into that drop-down then you move on if it’s non relevant. With radio buttons you cycle through the images. As much as anybody else, we light images on our software. We like to add them for flare. We also have a tendency to forget that those images are not necessarily key to the operation of the application. So for instance, if somebody logs into an application and they have to scan through five or six images to get to the thing that they really want, which is a link that they intend to click, and they are not for whatever reason using a keyboard that allows them to use the shortcuts and hotkeys for their screen reader, they find that to be frustrating at the very least. It’s non assistive and it’s not helpful. To a great degree I need to ask, “Why are you putting in images that are not related to what you’re doing?” We’ve all seen the worm give some bla bla bla bla from Microsoft products. It’s filler content. A lot of our images are filler content. They’re there to make our applications not boring. If you can’t make your application not look boring by being relevant, you need to work on the relevancy of your application more than you need to be filling up the user interface with images. Images. You’ve got some sessions today about ARIA labels and ARIA roles though the reality is, if you for whatever reason feel like you have to have those images, please let me implore it upon you, make it hidden. It really isn’t there from a usability standpoint, so it doesn’t need to be there from screen reading stand point either. Headers. I would bet some of you are doing headers wrong. I know you’re doing them wrong because all of my vendors are doing things wrong in third party software. And I don’t need we were doing them wrong. Headers are not for configuring the appearance of your fonts. They may have been in 2001 but they are not now. Headers are in fact what they say they are. They’re headers. They in fact are quick scan points. Especially if you’re using assistive technology devices like screen readers, to get to the content that you actually care about. The problem with headers to a great degree though, is that lots of different legacy code has headers in there to shift things around, move things in relationship to one another, set font sizes. If you go back and look at code written circa 2002 2003, it’s going to have badly use headers in there. In fact, it’s going to have the craziest in the world. It’s going to have out of order headers. You’re going to have a header one, that goes to a header three, that goes to a header five, back to a header two, back to a header one. You’re going to ask yourself, “What were they thinking?” Well what they were thinking was, “That’s easy. That make it look pretty good.” And realistically speaking part of our process was cleaning up code and making sure that that wasn’t the case any longer. So if you’re doing headers in that fashion, realistically you need to go back and revisit those. More importantly about headers, something that is extremely powerful about headers, is that headers are also usable in Microsoft Word. I don’t know how many of you use them as Microsoft Word. If you’re not, you should go watching youtube video on that. It actually makes your documents you embed it significantly more accessible. And I will tell you if you’re embedding PDFs, PDFs don’t scrape well. And so you have to embed inside PDFs markup that serves the same function as headers, if you want them to be accessible. Because that’s how you move around inside long strings of content, if you don’t have another mechanism for doing it. And colors. So big shout out to Brandon in the back corner. We hired Brandon, well I don’t know, I’ll say less than three years ago. Brandon is colorblind. He will gladly tell you that. And he will gladly tell you that our color selection his first part was bad. Why was it bad? Well it was bad because we assumed things that were not true. Like for instance, we assumed that a pop-up box that said “warning” or “this is an issue” or “this is bad” in red was helpful, and just the informative box being blue was fine. And a box and everything and everything that succeeded was green. Well that was great. It really wasn’t helpful to somebody who couldn’t see those color palettes. And that seems really obvious but it turns out that color blindness is one of those things like snowflakes. If you’ve met a thousand colorblind people, you’ve met a thousand colorblind people. Color blindness is not uniform across the shades and spectrum and so it turns out, when you get something back from axe that says, “Hey, this doesn’t look great from a color standpoint, you should probably trust that. It turns out that in fact, some people can not even really differentiate some of the high contrast colors from one another because they simply don’t see in those spectrums. So if you were here earlier, Brandon asked a question about iconography. About an exclamation point, or putting a check mark for success. I would encourage you to understand that that is beneficial for that particular use case. I would also encourage you to remember that those checkmarks and those exclamation points, if they are not in some way labeled so the someone using a screen reader knows what on earth those are, has only managed to make something better one class of users while making it significantly worse for another. So here’s the challenge that we kept running into. So we’d make something better and then we’d make something worse. And pop-ups are the thing that we may worse, five hundred times. It turns out, just don’t do pop-ups. Jon’t do modal changes. Don’t do crazy dynamic actions that you’re not prepared to deal with confusion regarding… If you see a pop-up come up, you go, “Oh, pop-up came up.” Now you can label that pop-up so that when it comes to up it basically says, “Hey I’m a pop-up and I have things to tell you. Let me tell you things.” I can suddenly start talking about an entirely different conversation right now than web accessibility, and that’s like a pop up to this presentation. You’d be like, “Why is he selling me steak knives for ninety ninety-five.” Realistically speaking, pop-ups are an atrocious thing to have to deal with, as far as keeping track of what you were doing and where you were at on the page. But more importantly, just because we sent you back in focus to where you were just at doesn’t mean that you feel like you went back and focused to where you were just at. Because remember the thing that we’re now telling you about we, hadn’t told you about before. And so if you don’t get your focus right so you’re sending them back to the last thing they interacted with, not the next thing they can interact with when using a screen reader… It turns out, Now they’re just lost because of your pop-up. Now they have to sit there and go back one or two steps and go, “Yeah I think I’m right where I’m supposed to be. And notoriously, across all of the web browsers out there, pop-ups and modal functionality, and more importantly focus elements, just don’t work uniformly. So you can say, “I’ve got it working in Firefox and Chrome.” Yeah we did that. Didn’t help the person who is using IE with JAWS. Kind of frustrated them really. Same thing is largely true… You could say, “Hey, this works really great with IE now” and it’s like “yeah it doesn’t work with Safari especially on mobile.” And so my recommendation to you on pop-ups and modal changes is don’t do it. Come with a better design. If you feel like somebody needs to be notified of something that way… I would even strongly recommend that you redirect them to another page and they can say, “Okay. I’m on this other page. I know what that’s about. I can close that tab and go back to where I was last at.” Really if you’re doing that, you still probably have a bad design and you need to go back and sit down with your UI team to figure out how you can make that better. When it comes to complex application pages, they’re doing lots of things where they’re auto-populating for you. We have a thing here on campus called person search. Person search allows somebody to go to one of our applications and start typing in their last name, their first name in a list of those people. You need to be very careful what that does. Because much like a pop-up, that comes into the next step which is too many steps; cognitive load. So we get the advantage that when people walk into our systems, we can grab their login. And we know all manner of things about them. And we auto-populate absolutely everything we possibly can at this point. We don’t want somebody needing to put things, this extraneous information. It slows them down. It’s an interface headache and largely to a great degree makes for a lot of these bad designs. From a short-term memory standpoint, what was I talking about 15 words ago? Most of you couldn’t tell me what 15 words were. It turns out that the human mind, as far as a list of information goes, will really only hold about seven items. In fact, most of you if you try to rattle off PI, unless you were in some sort of contest when you were in high school or middle school, probably can’t get past like 3.141516 or whatever. You just are going to. You don’t care. And so over a short-term memory standpoint, if you give people a complex interface, that complex interface is unusable. One of the worst parts of this for us is… let’s talk about college missions. College admissions is an excellent example of something it has a whole lot of steps involved in it. And if you put all of that on one page, we have a vendor now that we do college admissions work with, it’s hard for somebody who cannot see that interface to interact with that interface. And it’s even harder sometimes if that interface is not just something that they can’t remember what steps the’re doing. They also run into a situation of not even remembering what page they were on, what page they need to go back to. I’m saving my application, I want to come back ten minutes later. I want to come back two days later. It’s hard to work through an interface like that. Keep your interfaces as elegant and as simple as you possibly can. The old adage of, “if you need a right-click, your interface is too complicated” is true when it comes to accessibility. Don’t make interfaces that contain extraneous steps if you can absolutely pre-populate, pre-fill, or pre assist your users in dealing with that at all. If your code doesn’t work with IE guess what? Microsoft still ships it with Windows 10. They can’t get rid of it. You can’t get rid of it. You’re going to lose users if you don’t support the most of legacy of browsers. There are a lot of institutions, banking being a good example of it… If you work with the banking industry IE is still king of a lot of their systems. Why? Because terrible terrible machines called ATMs were constructed to run with IE as part of their software interface to a great degree. If it doesn’t work with Safari, it’s not going to work on the iPhone well. And it’s not gonna work on the iPad well. Andf you don’t think those devices matter, you’re going to lose a huge number of your users. If you are hung up on Chrome, if you’re one of those 67% of people that says, “you can pry Chrome from my cold dead fingertips”, realistically speaking you’re going to lose a chunk of users. We really learned along the way that to include everybody that requires going the extra mile. Every web browser, every screen reader, every piece of assistive hardware technology we could get our hands on. And to sit down and work with people who use those software technologies every day. I’ll tell you, internal QA fails of no one on your team uses a screen reader, assistant pointing devices, etc. If you’re trying to do this by throwing paint at the wall and hoping that it sticks, you’re going to be doing better than you were before you cared. But you’re not going to actually meet users where they’re at, using your software the way that you intended them to. Unless you get them in the room and let them show you the struggles that they’re having. At the very least, you need to have somebody in your team that is the blindfold expert. That you make wear the blindfold and sit down and use your software and suffer through that. So they can come back and tell you, “man, that it’s just terrible.” Build relationships with anybody in your organization who would have that level of expertise. If you don’t have anybody in your organization, you need to make friends. You need to start coming to external organizational meetings in the community. You need to come on over to your local higher education institution and partner with them on the projects that they’re working on that are community focused. You need to have people in your sphere of impact that can be those expertise specialists on these particular topics. And the best intentioned mock-up of usability testing is never as good as having that feedback. It doesn’t matter how good you get at setting up a process model for going through and stepping through with unit tests. Trying to verify your code with your own people and your own staff. Until you’ve got be able to actually use it and they depend on it, you’re not going to get true feedback. So putting it all together… One of our most important things was iterative software development. I don’t know how many of you like use the word actual. You think of that as an idea. Iterative software development you make a change, you see if it works. Go back to make another change, you see if it works. Try making usability changes 12 at a time. I will tell you lose your users. They get confused. They do not know what you changed, why you changed it, what you were thinking. One change at a time when you are working with users. Or at least one profound substantive change at a time. When you make any changes, you make it too difficult for them to figure out what you changed, what’s going on, and why. From a triage standpoint, if you want to have the most bang for your buck right away, focus on your navigation issues. If somebody can’t navigate around their page first and foremost, they’ll just walk away from the page. They’ll walk away from
your application. They’ll say, “No. Not gonna do that. It’s too hard. I’m going to
get somebody to come assist me with this, or I’m going to find an alternate solution.”
They’re not going to bang their head on the wall over and over and over again because you have elements that are hard to click. Or you have elements that they can’t discern from one another. Or they simply can’t be used with a screen reader. Second one, fix your focus. Get rid of as many dynamic changes and pop-ups that you possibly can. Pre-populate as much as you can. Remove extraneous information from your applications and your interfaces. Keep it on the back end. Look at it in the database, don’t put it in the front end if it doesn’t need to be there. It needs to be verified by your users. Consider your mobility challenges. Radio buttons, et cetera. A big one to a great degree if you have elements too close together on your screen. Simple fact of the matter is it’s hard to select them if you have limited movement capability. The hardest one, WCAG 2.1. Cognitive load. Cognitive load. That’s hard. They don’t give you a specific rubric on how to hit that perfectly in the guidelines. Cognitive load is, and you know when you see it, is when you’ve made an application and you’ve made an interface it’s so complicated, that you realize that if you were forced to deal with that blindfold on, you wouldn’t remember everything that happened at the end of the process, what was at the beginning of the process. If you’re not going to be able to do it, no one else is going to be able to do it. But really the thing that was the most important to us was asking the question, “Did we program it this way because it was easy, because we had somebody who knew how to do it that way, because we’ve always done it that way, or did we program it that way because it was best for the users. So last, don’t be afraid. Especially if you have good partners. Go in, break things. I’m a Linux user. That says everything you know about me in a technology standpoint. That means I like breaking things and not having a working system. But in this very case everything… You’re not going to make anything better if you’re terrified of change. Change only happens when the pain of staying the same outweighs the pain of making the change. Which is why people are getting
sued. And it’s why we need to do this from a liability standpoint. But we always need to do it because it’s the most inclusive thing to do. And the pain of your change to make software more accessible, to make your applications more accessible, is ultimately still significantly less than the pain of somebody who’s been struggling
to use them over a long periof of time. It will be hard. You’ll get better along the way and all of your efforts will stack on top of each other. Your team will get stronger. More importantly, everything you build going forward will be better than it would have been had you not dug deep and made this a top priority. So one of my favorite proverbs in the world, is graduating an African proverb. As an interesting aside, it’s a proverb from the Buntu people. “If you want to go fast, go alone. If you want to go far, go together. And when it comes to something like accessibility, accessibility is by definition, an embrace of the diversity of all users, all people, everybody in the community, making sure that we all go as far as possible together. So with that, any questions, thoughts, comments? That is correct. The question was, “What type of issues do we run into with radio buttons?” And there were actually two major challenges we had. Users had a hard time selecting them. Especially when they’re stacked on top of each other, one after another. It’s a smaller target point. If you’re using an alternative mouse, the alternative mouse movement is very difficult sometimes to select right on the radio button itself. So you are going to have a radio button, you need to encapsulate the entire question, or the entire selection in your click area. So that’s something that somebody has an easier target to hit. It’s still not optimum to a great degree because of how we have a tendency to bind radio buttons very close to one another. They still ran into struggles when we did that. The other challenges we ran into with radio buttons is radio buttons, to great degree, especially when somebody shifting between platforms… Let’s say they use an iPad with VoiceOver. And then they have a main desktop with JAWS. The different screen readers handle radio buttons differently as far as how they read them out, how they read the content. And that created challenges as far as tracking what they were selected… what they needed to use as their keys move between them and so on. They’re just poorly supported at this point. Users who were brought in external were the ones that actually pointed out that this was an ongoing challenge of concern. We didn’t internally recognize that there had been an issue with this. But based on the feedback of people that predominantly screen-reader based, they provided the feedback that that was adding challenges to their ability to select things to the best of their ability. Yeah. So the deal with embeded help… to make it accessible to somebody who is going to be struggling with the modalities of having a pop-up, the thing that we would probably recommend based on our experience, is to go back to something that’s very old-school. Which is to have a back library and actually send people to an entirely alternate page that clearly identifies what it is they have. In the back library they can move up and down within that help documentation. But instead of thinking, “Hey, I’m suddenly here and I don’t know where that is and how I’m going to close it. The ability to close a tab is pretty universal across all devices at this point. The selections to close the modal windows depending on how you structure your modal window, will operate differently. And so to have that uniformity of experience, that was more successful for us. Anyone else? All right. I’ve got less than a minute at this point in time. We really appreciate all of you being here and we hope it was informative and useful in some way. Thank you. The link to the slides is on the schedule. The link to provide feedback is on the schedule.