Category: 101

The Hard Part of Web Accessibility

a11y-sailorLeave a comment
Reading Time: 6 minutes
Collage of images showing UX team designing user interactions and 3 user types on the bottom.
A collage of images showing on top a UX team designing user interactions. Bottom images showing intended users by output type. A man with headphones for audible output. A refreshable braille display for tactile output. An enlarged eye is seen through a magnifying glass, for visually magnified output.

The hard part of Web Accessibility is empathy. By that, I mean the part where a development team has to emulate users with disabilities to provide a solution. As opposed to sympathy, which is just caring about the Web Accessibility cause, and saying: “somebody should do something about it”. But then, navigating and testing (hands-on) while emulating users with disabilities is hard, and a process. A slow one.

Of course, hiring people with disabilities to do the testing and providing feedback is the best solution. Unfortunately, this is still not a widespread practice. Most of the time not in the hands of designers and developers to do the hiring. However, emulation is a good strategy, while keeping in mind certain details.

So, empathy equals user emulation, and user emulation is hard. This “hard part” proves to be hard most of the time because it’s usually not “on the radar” of the “usual” development practices. Hence, most of the time not “visible” to team members. The hard part is usually harder when neglected from the very beginning of a project. At that point, it just seems like a very time-consuming inconvenience to retrofit everything. The latter is unfortunately the most common approach to Accessibility. Retrofitting takes 10 times longer compared to what it could have taken if done “from scratch”.

Nevertheless, the “from scratch” approach generates a high level of anxiety among developers and stakeholders of the project. It gets perceived as if they are spending too much time in proper code semantics. Not in actual features and functionalities. Then we hear: “time is money”, “the client wants it for yesterday”, “not enough resources”, etc. Yes, all of the above, also makes part of a hard truth: “no features, no sales”.

Annotations to the rescue

Tackling implementation with Web Accessibility Annotations makes it less time-consuming. Even when developers aren’t “that much into emulation” or are still ramping up their accessibility knowledge. With annotations, they will know what needs to be there, code-wise, and why.

That said, a lot of time could be saved if Web Accessibility is considered at early stages. Like while UX Design and Visual Design stages are starting. If Web Accessibility Annotations are clearly communicated to developers from the beginning, they will be able to implement them faster. Of course, best if crafted at the very beginning. Most common categories for these annotations that will help speed up projects and make the hard part less painful are:

  1. Accessible Keyboard Patterns being standard.
  2. Labels and Descriptions provide context for all users.
  3. Headings make sense if nested.
  4. Landmarks and Regions are well organized.
  5. Status Messages are meaningful and punctual.
  6. Screen Reader narration UX.

There are great design tools to communicate Web Accessibility Annotations. They can also all be communicated to developers with a spreadsheet or a text document. Yes, it’s time-consuming to populate a spreadsheet with all those details, but it’s worth the effort in the long run.

By keeping in mind some details under each category, we will be on our way to crafting them correctly.

Accessible Keyboard Patterns

Keep in mind:

  • Keyboard navigation is the foundation for most Assistive Technologies. All UI components should work with the keyboard or provide a similar experience while using the keyboard. Source order matters, avoid breaking it, and thinking it can later be arranged using CSS grid or absolute positioning.
  • There is already a standard for Common Keyboard Interactions for most UI components, no need to reinvent the wheel. Have a cheat-sheet handy with all those included in your UIs, to avoid regressions.
  • Not everything on the UI is about “tabbing”. There are other keys on the keyboard as well. Some are exclusive to Screen Reader use. 

Labels and Descriptions

Keep in mind:

  • All form elements and buttons should have labels. Text in label should make sense when audible (when vocalized by a Screen Reader).
  • A placeholder is not a label, use both, even if repetitive, or be creative to avoid repetition.
  • Don’t be afraid or annoyed by repetition. What may seem straight forward for some users, may not provide enough context for other users. Be inclusive: design, develop and deliver for all users.
  • Screen Reader users will get context from the labels and descriptions they hear. Trust your eyes, but also trust your ears. If you don’t hear it’s not there.
  • Don’t overuse aria-label, it’s invisible to sighted users, and it will override text in native labels for Screen Reader users.
  • Provide descriptions through aria-describedby attributes to give Screen Reader users more context if UI is complex. Use visually hidden text styles to provide context or instructions if you can’t provide aria-describedby due to code practices reasons.

Headings

Keep in mind:

  • Headings are for arranging or structuring content on a page. Not all big font instances have to be headings. Choose wisely.
  • Most Screen Readers allow “headings navigation” by just pressing one keyboard key, H key for JAWS/NVDA. Make sure the heading structure will make sense if users were to skip content by headings. Will they land on meaningful content?
  • Most Screen Readers can produce a list with all the headings on a page. This allows users to browse the list and jump to a specific heading on the page. Write down that list and structure it. Does it make sense if you read it out loud?
  • Some Screen Readers like NVDA will “nest” headings when listed. Organize your headings in a way they make sense, similar to an expandable Table of Contents.

Landmarks and Regions

Keep in mind:

  • Similar as with headings, Screen Reader users can list, navigate, and skip landmarks and regions by pressing only one keyboard key, R or D key for JAWS/NVDA. This is a capability only Screen Readers have. They must be well organized and make sense when listed.
  • Screen Readers will announce when users enter and exist a region or landmark. If you have more than one region or landmark of the same kind, then label them for differentiation. E.g.:
    • <nav aria-label=”top navigation”>
    • <nav aria-label=”breadcrumbs”>
    • <nav aria-label=”footer navigation”>

Status messages

Keep in mind:

  • If you remove something from the UI, don’t assume the user will “see” it’s no longer there. That’s not enough for Screen Reader users, they also need to “hear” it’s no longer there. Use aria-live or role=”status” to notify user of any changes that may affect them.
  • Same as the above but for element that weren’t there before. Notify users when new elements are introduced on the UI.
  • Don’t overuse role=”alert” this is a very aggressive and intrusive kind of notification. Use only when needed, for everything else use aria-live. 

Screen Reader narration

Keep in mind:

  • The Screen Reader user experience should make sense throughout the whole user journey. Think of it as a person telling you over the phone what they are doing at every step. The “listening experience” should match the user interactions. Write it down and make sure developers receive it. Along with specs, wires, and visuals.
  • Silence is bad. Knowing beforehand how the UI should “sound like” will help spotting and fixing silent spots.
  • Use proper semantics. A link is not a button, even if you make it look like one. Screen readers will vocalize the true nature of the element and users will act according to what they hear. Screen Readers can also list Buttons and Links separately, so they should make sense when listed apart. 

When browsing the web it’s clear that keyboard interactions, code sequence, labelling and status messages are probably the most neglected issues. Then, in my experience, thinking we can later rearrange the order of the components with CSS Grid, and enforce focus management with JavaScript, sets the ground for very unpleasant surprises.

Other Pain Points

  • Tables can also be problematic, especially if responsive. They are a complex topic worth an article, or several, of their own. Noted in my to-do, for a later time. For now, keep in mind Screen Readers can also navigate by Tables on desktop, T key for JAWS/NVDA, and have their own keyboard interactions. Therefore, semantics matter quite a great deal here. Oh! … and they sound different on mobile.
  • Form validation is also complex, although it could be very simple. It’s a controversial topic mainly due to the overuse of “dynamic validation”. It looks great visually, but it’s not very inclusive for Screen Reader users. They will hear an error as soon as they start typing. Creative solutions are needed to produce an inclusive UX. This topic too deserves its own article(s).

To wrap up, and clarify. Let’s not be fooled by thinking Web Accessibility Annotations is all that’s needed to get Web Accessibility Implementations done. They are just part of the specifications. It’s a reference. It helps. But it helps even more when team members are familiar with Screen Readers’ use and interactions. With how components and elements sound like. Then annotations will be accurate, UI/UX and code-wise. Like an audible mockup.

Avoid starting accessibility with the easy parts

a11y-sailorLeave a comment
Reading Time: 4 minutes
photograph of wooden cubes half piled up and half crumbled
An artistic photograph of wooden cubes half piled up and half crumbled, with a wooden figurine stuck headfirst in the crumbled side.

I often get questions about where to start implementing web accessibility. If there are easy parts to WCAG, and if it’s OK to start from there.

Yes, there are easy parts to WCAG. The easiest parts are those you really don’t have to do. Non-applicability, I mean all those success criteria that do not apply to your product or website. According to WCAG’s definition of conformance. If there is no content to which a success criterion applies, then the success criterion is satisfied. Consequently, there is great value in identifying those first. Every project is different, but for instance, if you don’t have video or audio in your project. In that case, you can skip those parts completely.

In my experience. I would say anything in the realm of automatic testing is easy. Easy to test, easy to fix. Then things start to get difficult when we need to manually test the User Interface. Mainly because there is a steep learning curve as to how exactly it needs to be tested and by who. Therefore, testing for Screen Reader is the most difficult part, in my opinion.

The easy parts

Now getting back to the easy parts. The following are easy: non-text content, sensory characteristics, use of color, contrast, page titled, link purpose, multiple ways, consistent navigation, consistent identification, language of page, link purpose and maybe error identification too. Mostly all those things on the web designer’s end. It almost seems logical to start there. Although, in my experience with transactional websites, these are huge time wasters. I’m not saying don’t implement them, they must, but not first. Change or adjust them at any time. However, implementing them first usually gives a false sense of accomplishment.

By the way, I’m intentionally removing the success criteria numbers in the previous paragraph. Removing the numbers makes articles more digestible, some readers have told me, especially for beginners. It seems numbers give the article a technical flavor. So, I will do this when possible. This is not a technical article, it’s more of a cautionary tale.

The disadvantage

One disadvantage of starting with the easy parts is thinking your website is accessible because an automated test says so. Tests such as Chrome Lighthouse, may indicate your project is 98% accessible. This could be misleading for your project stakeholders (e.g., client, high management, project manager, developers, designers, etc.). Especially if they are not familiar with web accessibility and falsely think they have reached a near-perfect accessible website. As it turns out, automated tests only cover 18 to 20% of the accessibility issues. And doing it so, page by page.

It should be clear: there’s no replacement for manual testing. So, if you make it to 100% in Lighthouse, that’s really only 20% of the accessibility for the tested page. Not for the full website. I have come across this misconception many times. It’s demoralizing for stakeholders and developers, finding out there is still a remaining 80% work to be done. Once they thought it was ALL done.

It’s also tempting for some stakeholders to claim a site is “half-accessible”. By taking fulfilled success criteria based on non-applicability, and then add them to the previous automated test percentage. Inflating numbers is a terrible idea. This doesn’t make a site more accessible.

So, where to start?

I have heard many times the claim that the first 3 steps to Accessibility are “easy”. Those steps being: Keyboard Navigation, Form Labels and Automated tests. I agree with this approach, but I kindly disagree with Keyboard Navigation being easy. The more interactions you have on one single page, the more complex the Focus Management becomes. However, I definitely agree Keyboard Navigation is the best place to start, even if it’s not easy.

Form labels, in a perfect world, are easy only if using native HTML elements. Yet, a rarity in real life these days. The more developers use <div>s and <span>s for everything while coding forms, the more dependent on ARIA roles and attributes those forms will be. Once crossing the ARIA imaginary point-of-no-return, then the next thing we will run into is Accessibility Patterns. Defining or reconstructing these patterns takes a lot of focus management work. Not an easy task past that point, but a must-have by then.

Anyway, in my experience, implementing the “hard parts” first sets a foundation. To support what you will add on top. The previously mentioned easy parts. Accessibility is not a one-time project, it’s a process. There could be regressions and we want to know where they are and how to avoid them.

Hard parts are time consuming

Yes, it takes time to do the hard parts first, and time is money. In real life, stakeholders get desperate with deadlines. Developers want to start features and functionality without mockups. Managers want to add look and feel quickly to show progress. Those efforts need direction. Developers for sure can start features, but making sure they are operable with the keyboard, not just the mouse. Progress on design is perfect as long as it doesn’t break keyboard navigation.

If you are working on a website that the client will customize later. Then fine-tuning contrast, fonts size and use of color is something you can put at the bottom of the to-do list. Better to concentrate on building on top of the keyboard navigation experience and visible (and audible) labels. But here’s the thing, this is also no different if you are working on a website that is “final”. Meaning the client won’t customize further. In this case, keyboard navigation will give designers better arguments as to where to place components. Other than just “design trends” or fashionable practices. It’s harder to roll back a component’s position and break keyboard navigation, than it is to roll back from color, contrast, or size changes.

Having said all that. The hard parts don’t have to be “that hard”. UX designers can help from the very beginning. By identifying things like Intended Keyboard Patterns, Visual and Audible Sequences, Minimal or Specific Screen Reader Narration.

The choice is yours. As I said before, every project is different. Just don’t let the easy parts consume the time you could be spending on the difficult parts. Accessibility needs to be implemented gradually, like onion layers, following Inclusive User Journeys. Instead of just literary complying with success criteria without understanding their meaning.