Lessons Learned: How to Review and Improve Internally Built Applications

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.
Jonathan: That gives me something to do. Shawn: It does. Our technical tool kit that we use for the process really comes together. And there’s a key batch of tools that we have our developers set down and install on their workstations. The first of foremost one is axe. I don’t know if you ever heard of axe. Axe is a plugin for web browsers. It works in both Chrome and Firefox. Axe has become, in a lot of ways the gold standard, as far as having a tool built into your browser, that allows you to do a quick analyze on whether or not you have accessibility issues. We’ll come back around to that a little bit. And we’ll talk a little bit why we chose axe over the other alternatives. We have screen readers installed in our area. We have JAWS installed, we have NVDA installed, and we have voiceover setup. We have the JavaScript Bookmarklets site installed on several computers. It’s a quick easy web address. And you’re going to get more information on each one of these as we go. And I have a little tool that I use called HTML-codeSniffer So… Axe, the browser extension. Why choose axe? Well first of all, it works on multiple browsers. And the reality is, this is not just about making technology that is immediately accessible. It’s about making it accessible to everybody who comes to your site to use your web applications. Axe is super super easy to not use. In fact it’s so easy that our training process really required setting people down in a room and spending 15 minutes with them and saying, “This is how you run an audit in axe.” It does not get much easier than that. And that allowed people who don’t necessarily work all day in CSS, they don’t spend all their time in JavaScript, to be able to pick apart very quickly, “Hey, this is not up to par.” And it allowed them to start documenting it in meaningful ways. And those documents are what we refer back to to build specifications, to really understand how we need to change the design or change the fundamental programming of applications. Axe isolates coding violations. It’ll tell you that something needs review or that it doesn’t meet best practices. And that includes quick easy things like making sure your Aria roles are configured the way you need to. Things that you overlooked because somebody was cranking out the script fairly quickly, and they didn’t get something labeled the way it needed to be, et cetera. Past axe, you have the chance to see it downstairs. The reality of the matter is, you have to have a screen reader. In fact you need to have a lots of screen readers. And here I’m going to tell you why. NVDA is free. Anybody can have it. Anybody can use it. Setting it up and configuring it, on the other hand, that’s another conversation. The reality is, its defaults as far as its voice are very robotic. It does take a bit of getting used to and it is not very natural in its language usage of abnormal terms, things that are outside of its lexicon. But it’s getting constant improvements, it’s being supported by Google, Microsoft and Adobe. JAWS on the other hand, JAWS has been around forever. Or at least as forever as accessible software has been around which means, if you know somebody in your organization that needs to use a screen reader for any reason, I would bet you frankly dollars to nickles that they probably use JAWS or we’re a recent JAWS user. JAWS has the benefit of being incredibly established. It also has the pain of being incredibly established. JAWS was constructed in an era of Windows 95 Windows 98. It was constructed in the era of Internet Explorer five and six. And it does an incredible amount of heavy lifting for the user. The challenge of that is, JAWS thinks for itself a good portion of the time. And it has its own way of wanting to do things. You want to meet your users where they’re at? You need to support it. Coding against NVDA experiences or VoiceOver for Apple, it’s not going to get you there. The reality though is, if you have young people that are going to be using your applications, they’re using your sites, more and more of them prefer Apple products. And VoiceOver is the built-in solution to Apple products. And it’s actually reasonably good. Works very well on an iPad. Does a very good job for somebody on the iPhone. There is a challenge to VoiceOver and that really is that voiceover works best if you build your stuff so it works properly in Safari. And for those of you who are kind of groaning at me by the way than you look because I said Safari, that’s simply the reality of the matter. I have birds in the back cheering for Safari. All three of them need to be installed. All three of them need to be used, just like using your web browsers. So what did we learn? First thing we learned is that screen readers are crazy not intuitive. In fact, I had a team of people sit down with screen readers. And they achieved absolutely nothing for a prolonged period of time. It turns out that if you don’t use a screen reader, if you’ve never used the screen reader, you don’t probably know what the hotkeys are. But more importantly, you don’t know how people actually use screen readers. So even if I taught you the hotkeys and I told you, “This is how the screen reader is used,” I’m going to tell you right now, you’re going to get it wrong. One of the first important lessons we learned was sitting down with somebody from the Disability Resource Center, and watching them use their screen reader, and realizing we were woefully outside the scope of how they were using their screen reader. But if you want the experience what your application is really like to use… Everybody wants to peek. Everybody wants to look. They want to use their screen reader. They want to hit tab-tab-tab-tab-tab. They want to go through the hotkeys. They want to see if they can search through the headers the way they need to. But the reality of the matter is, until you go all in you put a blindfold on, you have no idea how bad your stuff is. And all of a sudden you realize, “I made this. I know what it looks like because I was the one who created it and I am lost as far as where I’m at on screen. I don’t know how to get back to that thing I know is there because I put it there.” And then you have just a tiny taste of what it’s like for somebody who can’t see the screen. To try to use it for the first time without that mental map, without that understanding, and suddenly you have that clarity. Screen-readers won’t necessarily help you figure out how your code is bad. But they will, more than anything else, help you know that it is. JavaScript Bookmarklets. I’m a big fan of examples. Anybody hear use Stack Overflow? Anybody here willing to admit that 80% of their code comes from Stack Overflow? Okay. It turns out examples are incredibly powerful things. The JavaScript Bookmarklets… I’ve got the URL up there if you want to jot it down. It’ll be in the slide deck as well. They’re handy snippets of JavaScript that show how a person can use everything from ARIA, to using images and headings, tables, landmarks, you name it, and more. What they are is an opportunity to get a sense of how you should do something, if going to be doing it in terms of WCAG compliance. Now everybody’s got Google. Everybody can go look up options. They can look up how things should or should not be done. Realistically speaking though, having a quick easy reference speeds up your ability is a person working on these projects significantly. At the end of the day, I am NOT a person who likes to bother with trying to store everything in my head any longer. My staff would tell you otherwise but to be fair, it is better to always go back and look at your source documentation if you can. Because realistically these are updated on an ongoing basis by the W3C and other organizations. So this is a handy tool to refer back to. What we learn from it. It’s a great primer. It is incomplete compared to WCAG 2.1 triple-a guidelines. If you’re trying to go all-in and hit absolute industry best practices, it won’t get you all the way there. It’s a quick handy referral to kind of help you with the stuff that you keep thinking, “I should have remembered that,” after the 15th time but you realized that you don’t. They do not fully assist in guaranteeing compliance. But they will at least make sure that if you’re moving along, you don’t have to step too far out of what you’re doing to get stuff cleaned up the way it needs to be. HTML-CodeSniffer. Boy. It’s easy, it’s fast. It has limited language compatibility. It’s an incomplete assistant when you’re building applications because… Let me tell you a little bit about how we build software at Missouri State. Our internal applications are built on a MVC based design on the Grails platform being programmed into groovy language. Now I would bet most of you don’t program in groovy. I would even bet half of you don’t even know what groovy is. Groovy is a Java dialect that takes a lot of the advantages of Ruby and other fast prototyping languages and adds it into Java. It’s most famous for making it possible, when you’re creating variables, to be able to dynamically type them. And so you don’t have to have statically typed variables. There’s some benefits as far as some of the code being a little bit cleaner and easier to read. So this is really for HTML only. And yet I think many of us know to a great degree from an HTML standpoint, we overlook things accidentally. My personal favorite that we overlook a lot, is alt text. Alt text is really a situation where you can have alt text and it’s beneficial that it’s there. Realistically speaking though, most of the images on the Internet, really aren’t there to be helpful. Most of them are for stylistic reasons. Most of them are there because it makes the formatting of your page look nice. Ultimately, you can use aria-hidden and get rid of those to a great degree so your alt text doesn’t matter. But if you’re not going to be using Aria thoroughly, then you should probably make sure you have alt text so that people who are using screen readers, don’t run into that issue. But there’s a human factor to all of this and it’s not really just about screen readers. And it’s not just about WCAG 2.0 or 2.1. As the crowd of people who use assistive technology will know, this is really a partnership. We build software for people. If you are building software for something other than people, I applaud you for working in artificial intelligence and machine learning. I’m not sure how you ended up at this conference. Realistically speaking, software fundamentally is judged on its usability. So much so that there’s a company out in Cupertino who managed to make an empire out of having software that was recognized for its usability. Didn’t necessarily have to be more secure. Didn’t necessarily have to be faster. Didn’t really necessarily have to be all that much more usable. It just had to be more usable enough that they could build a reputation on it. If you want to understand and support all of the experiences, and all of the opportunities that your community with users contain, you’re gonna have to be attentive. You’re gonna have to get people in the room. You’re gonna have to get your customers, you’re gonna have to get your users, you’re gonna have to get their clients in the room, and have conversations about whether or not this software is usable for them. And ultimately, when they give you feedback, you need to celebrate and recognize that feedback for what it is. It’s a different type of expertise than you may have. The people on my team are very good at writing code. To be generous they’re not very good at necessarily understanding what every experience that every person that might use that code will have. When we partnership… we had a partnership with the DRC, we learned very quickly that our code was well-formed. It was code-compliant. It passed all of the tests that we put it through. It was also virtually impossible to use that first application. The fact of the matter is that there were no flags that we could say, “Hey, this is non-compliant software,” other than having people be a part of that. So know what you’re good at. Know what your team’s good at. But also know what the people you engage and partner with are good at. And when they give you that feedback, they’re probably going to ask you to change things you really don’t want to change. Like for instance, make it work with IE. But you need to do that. You need to be willing to go back and revisit the code and make it usable for everybody in that user space. So we’re gonna have some examples from our experiences working with them. I’m going to talk about radio buttons, images, headers, colors, pop-up messages/dialog boxes, and a thing called too many steps. So radio buttons. They’re ugly. Why are you using them? Don’t do it. They’re a terrible usability concern. They were very popular in 1998. If any of you have ASP pages that were written circa 1998, you know they were popular. If any of you can find me a modern web application that uses them extensively, I’ll give you a dollar. I went looking before this. I spent six hours looking for radio buttons. They’re mostly gone. If they’re in your legacy code, one of the first things you should consider when you’re updating that legacy code is to get rid of them. Why don’t you get rid of them? Well first of all, they work terrible with screen readers. Second of all, they don’t map very well in a person’s mind when they’re trying to figure out how many options they may have and what they need to select on. Okay. … The class is over everyone. Continuing on
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.

Leave a Reply

Your email address will not be published. Required fields are marked *