The Four Principles of Accessibility

Homer Gaines at UXDX Community: USA West. Video: https://www.youtube.com/watch?v=RUxx_sq2QdY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

How many people have a disability

[00:00:00] Good morning. Good evening. Hello from wherever you are and you might be listening. Welcome to UXDX West Coast. My name is Homer Gaines and I'm an accessibility professional and a front-end engineer. Today I'm going to be talking to you about the four principles of web accessibility.

[00:00:22] When we first start off, we think about web accessibility and what is it? What a lot of people don't know is that 15% of the world's population actually has a disability, which roughly equates to about a billion people.

[00:00:40] But when you're actually talking to engineers and product managers and so forth, at least I know I do: "People with disabilities don't use our products." That couldn't be further from the truth, because even here in the United States, just between the populations of 21 to 64, there's roughly 19.3 million individuals who have some form of a disability. So to actually think that someone who uses your application or your product does not have a disability could be incorrect.

[00:01:22] Because if you think about it, say for instance you were to take 8 million people and just tell them that they would not be able to use your app at all. What you basically did was just cut out the entire population of New York. So to think that individuals with disabilities do not use technology, or even your application, is not the way to think about things.

Visible and invisible disabilities

[00:01:42] Mainly because when we think about people with disabilities, this is what usually comes to mind. You see two gentlemen on the left who are speaking using ASL, American Sign Language. Or you see the young lady in the middle who has a prosthetic limb. Or the young woman who was walking with the cane and her assisted dog. And then you see the gentleman all the way to the far right who has mobility issues.

[00:02:12] Those disabilities are visible, but what about invisible ones? The things that you don't see. Because the largest category of disabilities is actually cognitive: you have autism, you have attention deficit, you have memory loss, and all of these cognitive disabilities can affect the way that individuals use and perceive our applications.

[00:02:40] And then, unfortunately, in this day and time that we live in with COVID and all, we have long COVID, those who have actually survived. Studies are showing that depending on the severity, 20 to 70% of those individuals can develop some form of a cognitive disability. Because what the studies are now showing is that not only does COVID affect the respiratory system, it also affects the gray matter inside the brain, which can lead to attention deficit and other memory loss functions. So we have to be more cognizant about how we are actually approaching software development and design, because obviously this number is going to continue to grow.

Perceivable

[00:03:27] And how do we get there? We have guidelines. One great place to start is with the Web Content Accessibility Guidelines 2.1. That's what we currently have. 2.2 is out and 3 is also in the works right now. 2.2 hasn't been finalized, but for right now we're just going to focus on WCAG 2.1, and inside WCAG we have the four principles of accessibility, which is what the WCAG is broken up into. It starts off with perceivable, operable, understandable and robust.

[00:04:09] So, perceivable. Perceivable means that when a user comes to use your product or is viewing your application, they are actually able to use their senses to perceive the information you're trying to convey. Whether it's someone who is visually impaired — they're blind, they may be using a refreshable braille reader such as the one that's pictured here. But for those who are sighted, even things that designers take for granted, like focus states or even error handling, things like closed captioning, especially with all the video that we are consuming online these days. How much of it is actually accessible to individuals who can't hear the dialogue? So closed captions are great.

[00:04:52] Or what about those individuals who have low visual disabilities, like low vision, where they can't see, or even being colorblind, where they have an issue with seeing different colors based on contrast? We have to be mindful of that. We have to improve our scannability.

[00:05:08] For years, as designers, we've gravitated towards using the focus outline "none", because we didn't like the default blue halo that went around focusable elements when a user was navigating the site. Why? Because a lot of us always said "it's ugly", "it doesn't fit with my design". Well, guess what, that really actually hinders individuals who don't use a mouse and have to use a keyboard to navigate around.

[00:05:43] So one solution we have for that, to improve the UX, is to customize those focus rings. Now we don't have that excuse of "well, it's ugly and I don't want to use it", because now we can use CSS to actually style the focus ring to match our brand aesthetics. One way you can do that is by either using the box shadow CSS property or the outline property.

Operable

[00:06:08] And that leads us into: people use different methods when they browse our products. How many times have we seen this? We have a design or we have a project laid out and we have a perfect path that we think the user is going to take, or we hope the user is going to take. When in reality, they find a completely different path to navigate our application. Yep, that's because everybody uses the web in different ways.

[00:06:41] Which leads us into operable. Operable means that we are meeting the individual right there with how they need to operate, and the modes of operation that they need to use to navigate through our apps and our products. Not everyone uses a mouse. Some people use keyboards, some people use switches, we have sip and puff. We also have head mice, where if the individual has mobility issues they use their head. Or even better, visual: we have eye tracking software where the individual is able to scan the page using their eyes.

[00:07:15] But we have to make sure that we are designing and building our applications, or our UIs, so that they are large enough for individuals to be able to focus on those elements, because they don't have the fine motor control that someone would if they were using a mouse.

Headings and logical reading order

[00:07:32] Headings. When it comes to navigating web content, this is one area that we see fail often, and it's how headings are actually used. I kind of attribute this to us growing up using word processors, because with word processors, when you went through and you chose your heading, you chose your heading based on how it looked. We really didn't think about the semantic meaning behind that.

[00:08:08] Those bad habits transferred over to the web and got lost inside either web authoring or design practices, to the point where when we started designing headings, or adding headings to web content, we didn't pay attention to the semantics. So therefore the semantics were all out of order. Case in point: in the first example we have an H3, an H1, an H2, an H1 and an H5. All over the place, when technically we should only have one H1 on the page. Multiple H2s, you can have multiple H3s and so forth, but they should all be in sequential order because of logical reading order.

[00:08:44] The reason being: 64% of screen reader users use headings to navigate through page content. Where you have someone who is sighted, they can scan content quickly, but for someone who may be blind or have low vision, they can't scan the information that fast or in the same way. They use headings to jump through, or landmarks, and if our headings and landmarks are all out of order, then that individual loses the correct context of the content that's being presented. So we have to be mindful of that.

[00:09:22] One way that we solve for it is, one, stop using the element itself for styling, but instead use the correct semantic markup and then apply CSS classes that allow for the correct styling that you would like. That way your design is perfect and the user's navigation is better.

Understandable

[00:09:46] Then we come to understandable. Understandable is being able to comprehend everything that is on the page, but it goes way beyond UI and UX as well. It's how everything fits together that allows the individual to navigate through your application without having any issues, creating any errors. Because one thing that we definitely want to avoid when developing and building our applications is that we want to reduce as many errors as possible. So making sure that our content makes sense, making sure that our navigation patterns make sense, or even just our behavioral patterns. How we expect the user to interact with our UI: we want everything to make sense.

[00:10:33] And I present this example here called User Inyerface. It is an online game that puts together different UX patterns that are actually found in today's web, on different websites, and it poses a challenge. The first challenge is this: fill out this form and submit it and go to the next. I think I spent about 10 minutes trying to do it. It is something that is frustrating and you will throw your computer out the window after you try to do it. But if you do that, don't blame me. I'm already warning you ahead of time, it's super frustrating.

[00:11:12] But that's understandable. We have to be able to understand how to use the interface, how to actually glean the information that we need from the products that we are designing. Jakob Nielsen says most people spend the vast amount of their time on other people's sites, and when they come to yours, they just expect everything to work the same way. So when we decide to try a new UX pattern — yes, it could be innovative, it could. But how far out are you actually going, and how much damage might you be doing to your actual brand experience and your navigation experience when someone is coming to your project?

Robust and responsive layouts

[00:11:59] The other thing that we want to be mindful of is that we want to make sure that what we're building, what we're designing, what we're putting forward, is robust. What this means is that we're meeting the individual where they are. We're not just designing for the screen that is in front of us or the tools that we are navigating with. We are trying to meet where they are with the particular software or hardware that they may be using.

[00:12:32] One area that helps us out is using responsive layouts. Responsive layouts allow your content to flow as needed to meet the different screen sizes and resolutions that we have these days. And what does that do? If you only focused on designing for desktop, now if someone comes with a smaller screen, they have to worry about scrolling. Responsive layouts help reduce scrolling. They help individuals with low vision, because they have to use browser zoom and screen magnification and they have a narrower field of vision. Responsive layouts help to maintain and bring things into that field of vision, which allows them to see and perceive information easier and be able to use your application in a more effective way.

[00:13:25] And we also have to remember that it's not just mobile. Mobile is not just a small screen. There was a project that I was a part of where our designer had a super max resolution and he was locked into designing for that. The developers had 13 inch MacBooks, and what we found out is that because he did not design for smaller screens and he assumed everyone was on desktop — a MacBook is considered just like a desktop, it's a laptop but it's not mobile — yet the application did not fit within the 1440 x 900 screen resolution size of the 13 inch MacBook. So we had to go back to the drawing board, figure something out and move some things around so the website would be responsive all the way down to mobile.

Forms, labels and over-engineering

[00:14:28] And as I mentioned earlier, you have a narrow field of vision for individuals who have low vision. So when you're looking to design and lay out your form elements, be mindful of doing columns, or doing multiple columns. What we want to do is lean more towards doing a single column. If you have to do multiple columns, make sure that it's responsive, because someone with a wide field of vision will see this, however someone with a narrow field of vision will see this, and now they have to use various keystrokes or other means of navigating the page using browser zoom or magnification to move it around so they can see the rest of the form in order to fill it out.

[00:15:15] If we do a responsive layout, you end up with something more like this: everything is in a single column. It's easier for the user to see and they can fill out the form in a timely manner. Something that's a little bit less frustrating.

[00:15:32] Same with switches. I know we've seen this particular pattern before all over the web, where you have your label and your control and they're separated. What does that do for individuals with low vision? The same thing as using two columns. So the best solution, instead of having them separated, because now you lose context — and if someone has, for instance, a cognitive disability where they have short-term memory loss, as they're traversing through it's very possible that they can get lost trying to find the other labels, because there's nothing to actually associate it because it's too far to the right. They're not together.

[00:16:14] So by keeping them together, one, you keep them inside the same field of vision, and two, you keep them associated with one another, which makes it easier for the user to find the information and interact with what they need.

[00:16:22] And also be mindful of over-engineering. It's really easy to make something simple overly complex when we're thinking about accessibility. Here's an example that I ran into. I was new to screen readers. This was early on, when I first started with accessibility, I was new to using screen readers. And when I heard that a disabled button reported back as being dimmed — to me, dimmed didn't tell me that the button was disabled. What it told me was the visual state of the button, which is dimmed.

[00:17:08] So, thinking I was doing a great thing, I went in and re-engineered a disabled button using an ARIA label, to show that when you were on the button the ARIA label would announce it was disabled. I reached out to some friends of mine who were more proficient at using screen readers than I was at that time, and they all collectively smacked me on the hands, like, stop. Revert everything you just did. Don't do that.

[00:17:39] The reason being, screen reader users are used to hearing dimmed being reported for elements that are disabled. What I also didn't realize was that I broke internationalization, because now, instead of it being reported back to the user in their native language, they would hear disabled reported back to them in English. I had no idea. So we have to be mindful of the solutions that we put forward and how we're actually going to go about engineering these, because again, something as simple as this, and I broke two things: screen readers and internationalization.

Empathy, and how it maps back to the four principles

[00:18:22] There's an accessibility advocate, she's a lawyer, she's amazing, her name is Haben Girma. This is one of the quotes that she has, where she says, "Ableism is incredibly limiting, and we need to be aware of ableism and all the different ways it comes into our technology."

[00:18:38] So what is this and how do you actually apply this? What does this actually mean? It means that we need to be more empathetic when we are developing and designing our applications. How do we get there? You need to have cognitive empathy, which is our ability to understand how someone may think or how they may feel.

[00:19:00] We have emotional empathy. This puts us in that person's shoes, so when we are designing a user flow and mapping it out, we need to be able to step outside of ourselves. Get out of the weeds, step outside, look at the high level of it. Put ourselves in someone else's shoes to understand how they actually may experience this navigation scheme or this new pattern that we're putting forth.

[00:19:35] And then we have compassionate empathy, when we recognize and realize that, hey, we may have done something that would cause friction for a user. It now allows us, by using compassionate empathy, to take action to make sure that we correct those issues or those errors that we find.

[00:19:55] And how does this all apply back to perceivable, operable, understandable and robust? When you apply empathy, you ask yourself: what can I see, or what can I not see? That pertains to perceivable. What can I do, and how do I even do this? Operable. Understandable. Does it work with all the technology that I'm aware of, does it work with assistive tech? Robust.

[00:20:29] Thank you for listening. I hope you enjoy the rest of the conference, and be safe.