WEB ACCESSIBILITY BASICS FOR A FRONT-END DEVELOPER. PART 2

Practical guidelines for front-end engineers and web-designers

Web accessibility standards and guidelines

How do we determine if an interface is available? And how accessible is it? Can it be made even more accessible? Of course, everyone understands quality in its own right, so standards and specifications come to the rescue.

Web Content Accessibility Guidelines (WCAG), a document describing a set of recommendations for developing accessible interfaces, have been developed for web accessibility. In 2012, version 2.0 of this document became the ISO standard.

The recommendations were grouped into 4 principles: perception, controllability, clarity, and reliability. And each recommendation has its own level - A, AA, AAA, which determines the accessibility of the interface. The greater the A, the better. A <AA <AAA. The interface is said to comply with WCAG 2.1 AA if it has implemented all AA-level recommendations.

How to make the web interface accessible

Today, the industry requires everyone to understand the basics of accessibility. In 2012, there was very little comprehensible and straightforward information about the A11y - mostly boring and sometimes abstract specifications. There are now plenty of articles, blogs, YouTube channels, and courses. One of the sources -  A11y Casts, where the author talks about assistive technology and accessibility principles in a convenient format (up to 15 minutes); and Udacity and Google's Web Accessibility course, which gives 80% of the basic understanding of accessibility.

Keyboard and focus

If you are working on a website or already have one, try using the keyboard interface only. From now on, Tab is your best friend. Also, try experimenting and testing how available web resources respond to Tab. For example, The New York Times - links to a page become active one by one with each click; An outline appears around the link, new elements such as the Skip to Content link, and you can generally scroll through the entire page simply by tapping Tab, jumping over all elements that can focus. You can go to the active link by pressing Enter. Convenient, isn't it?

NYT accessibility

The nytimes.com interface responds to the Tab key

The good news is that browsers themselves can handle keystrokes, and we, as developers, should simply not interfere with them. Here are some tips on how to put your browser's skills to the benefit of your users:

- Do not hide the outline. An outline is a gray (or blue in Chrome) outline that appears when you click on form elements or navigate from the keyboard. And it is so often not loved by designers. However, the outline itself is a lifeline when using the keyboard, as it plays the role of a cursor. There's even a whole resource for why it's bad to do - a {outline: none; }.

- Keep the order of the HTML tags according to the visual presentation of the page. Browsers and screensavers do not take into account the reordering of elements using CSS (order: n; in flexbox or float) when building accessibility tree, reading content and navigating the keyboard.

- If you still need to reposition the elements, use tab index, an HTML attribute that indicates the order of the elements when navigating the keyboard, adds or removes an element from the entire list of interactive elements on the page.

- Add a Skip Navigation link (see NYTimes.com example) to prevent users from scrolling through all the navigation to get to the content.

- Use focus traps when needed, for example, if you have a modal window on the page. The user can only move between the elements of this window, but he must be able to close this window using the keyboard. 

- Avoid accidental and harmful focus traps - situations where the user is stuck between several elements and cannot return to the content. This often happens when a pop-up advertisement pops up on a page that cannot be closed from the keyboard.

If you are working to implement a UI pattern (modal window, accordion, etc.), check out the recommendations from the Design Patterns and Widgets section of WAI-ARIA Authoring Practices. There are dozens of patterns and, in particular, their correct behavior in response to keyboard commands. It is not necessary to invent a bicycle - there are already standards.

Semantics and content

In order to display the page, browsers parse HTML, CSS, JS, build DOM, CSSOM trees, as well as Accessibility tree. A11y Tree is a simplified structured view of a document that uses assistive technologies:

semantic web accessibility

Accessibility tree built by a browser. Images from Google Web Fundamentals

While building these trees, the browser ignores errors, specifications, and tries to guess what the author was referring to. And it works well with HTML, but it's not an option for assistive technologies.

For example, let us have the following form:

<form>

  <p> Fill the form so we can get back to you </p>

  <span> First Name </span>

  <input name = 'fn' />

  <button type = 'submit'> Submit </button>

</form>

If you look at the form, everything is clear: I can leave the name, click the button, and I will be contacted. However, if users are unable to see the form and want to listen to it, they will hear:

Fill the form so we can get back to you.

web accessibility best practises

Edit text.

Submit button.

Not very informative. This form is a horror for assistive technology users because:

The attribute name input is uninformative (name = "f_n");

Input has no placeholder attribute;

The text First Name to the left of the input is <span>, and the browser cannot know that it describes the input (a completely different thing is the <label> tag).

You should not expect a person using a screen reader to fill out this form. And this is a good example of why specifications, standards, and validity are important. Invalid markup is the cause of incorrect playback of content by assistive technologies. Instead, HTML, written to standards, guarantees you a basic level of accessibility out of the box.

Here's an example of how to make this form more accessible by providing more information to screen readers:

<form>

  <fieldset>

<legend> Fill the form so we can get back to you </legend>

<label for = "firstname">

  <input id = "firstname" name = "firstname" placeholder = "First Name" />

</label>

<button type = 'submit'> Submit </button>

  </fieldset>

</form>

Semantics also applies to other HTML elements.

Alternative text images. The alt attribute doesn't just exist. If the image has not been downloaded or the user cannot see it, alternative text is the only way to convey the content. Writing this text is a whole piece of art, just like the names of classes and variables. If the picture is illustrative, describe it; if it's a comic book, describe the dialogue. However, if it's an icon or a carousel thumbnail, then maybe it's worth hiding it at all? Here are all possible combinations of image and alt text:

alternative text web accessibility guide

Screenshots from Wikipedia. Left to right: image uploaded; image did not load but alt text (Casey Stengel 1953.png); image did not load and alt = ""; image without alternative text did not load.

Proper use of headers. When people read books or documents, they occasionally review the content - a set of headings and subheadings with appropriate page numbering. HTML headers were created for the same purpose - to structure your document and make it easier to navigate. Users of assistive technologies use headers for fast navigation. I often find headers that are actually just text in font size 30, or vice versa, all headers are H2. I suggest using a simple rule: H tags for structure, CSS for beauty. And to keep in mind, why headers for screenreaders:

web accessibility screenreader

VoiceOver: A list of titles for quick navigation

Links and buttons. The whole web lives on thanks to the links. Without them, it would be just a set of single pages that only the authors and their moms would visit. However, as with headers, there are a few rules for using links effectively. If the user knows that he or she is looking for the link (for example, this is Wikipedia and the articles about mandarin and orange exactly have links to each other), he will call a separate list of links using the screen reader. Therefore, first, the link should contain clear text if taken out of context (for example, "Read more" does not explain anything, but "Read more about accessibility" is immediately clear). And second, the link is not a button. The link moves us from page to page, and the button sends data or changes the status of the SPA application. And the screen reader doesn't exactly expect href = "#" or href = "javascript: void (0);" in the link list.

links and buttons web accessibility

List of links in VoiceOver

HTML landmarks. You can beat all the divs. However, W3C does not waste time and tries to make everything easier for everyone. HTML5 Landmarks are not just hipster tricks, but a way to make life easier for users of assistive technologies, search engines, and developers. As you might have guessed, VoiceOver also lists all of these <nav>, <main>, <footer>, <article>. If the user wants to go straight to the footer, there are three steps (VoiceOver Rotor call, link list selection, specific link selection), and it's already there. This also applies to other tags. The screen reader provides context and additional information while reading. For example, reads <ul> and <ol> and says how many items in the list, what item number, etc.

ARIA

Technologies are out of place, and we already have dozens of HTML tags, but many familiar UI patterns, such as a modal window, tree, or tooltip, have to be implemented by ourselves. And the whole set of elements from which we build these patterns must be presented to the user of assistive technologies. This is precisely why WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) was created, a set of attributes that allow an author's markup to change the accessibility tree so that assistive technologies otherwise reflect the content. This is an initiative designed to revitalize the web for users of assistive technologies - to enable them not only to read pages but also to use web applications.

ARIA's primary attribute is rolls. It can change the element type for assistive technologies. For example, if you use an icon font and a particular character is important in your context, then the meaning of that character should be voiced.

<span aria-roll = ”img”

      aria-label = ”Asterisk icon”

      class = ”glyphicon glyphicon-asterisk”>

</span>

Each role can have states and properties that describe the state of an element with a particular role. For example, a button may have the attribute pressed = "true".

It seems that ARIA is a complex specification and it takes a long time to master it, but we use a simple algorithm:

- use native elements and tags where possible. Nobody has come up with a universal quality alternative to <select>, and to handle and respond to keystrokes correctly is another task.

 - use HTML5 semantic elements (header, nav etc) and add role = "header" role = "navigation" to them if necessary to support legacy browsers:

<nav role = "navigation"> ... </nav>

<main role = "main"> ... </main>

We are looking for a similar ARIA pattern if we implement an item that has its name - accordion, carousel, etc.

We apply ARIA Live if we send data asynchronously and change the page without reloading it. This is a way to tell a user who has difficulty seeing that the content on the page has been updated.

Styles

CSS is an integral part of accessibility. Styles are not just about design and vibrant colors. High-quality visual design and user-friendliness results, and they often return to user-friendly interfaces.

Responsive styles. No one will be surprised by responsive styles. However, it should not be forgotten that they are useful not only for smartphone users but also for users with poor eyesight. It is much more convenient to view a page in a single column on a 30-inch monitor than to "run" it using, in addition to the vertical, also a horizontal scroll. Do not block zoom and use larger font-size in media queries.

<! - don't do ->

<meta name = "viewport" content = "width = device-width, initial-scale = 1.0, minimum-scale = 1.0, maximum-scale = 1.0, user-scalable = no">

<! - "minimum-scale = 1.0, maximum-scale = 1.0, user-scalable = no" is a major anti-pattern ->

 

<! - better do ->

<meta name = "viewport" content = "width = device-width, initial-scale = 1.0">

Outline. As I mentioned in the beginning, not everyone likes outline. However, the good news is that it can be replaced. This will make both designers and users happy:

/ * custom styles for outline * /

a: focus {

  outline-width: 1px;

  outline-style: dashed;

  outline-color: red;

}

/ * or you can add styles for an item in focus * /

.my-button: focus {

  background-color: red;

  Text-decoration: underline;

}

Contrast. According to WCAG 2.0, text and images are required to have a contrast ratio of at least 4.5: 1 (you can read more about the formula here). It is difficult to determine, but the tools discussed in the next section do it for you. You can also choose a fairly contrasting color in DevTools:

contrast in web accessibility best practices

Select contrast combinations in DevTools. Color-picker shows compliance and adds lines to the palette separating contrast values ​​from less contrast.

Don't rely on color. When I was creating my first forms, the validation issue bothered me - input {border-color: red; } - and you're done. However, for a while, I worked with a colleague who has color blindness. And when he asked to help him with color, I realized what mistakes he was making. Since then, I've always added error messages to my forms. Here's a good example of validation that works for people with achromatopsia (people who don't see colors):

colour blind web accessibility guide

A design example for people with color blindness. Try it yourself with the NoCoffee plugin

How to test accessibility

Of course, remembering all the nuances of accessibility is not easy. However, understanding the basics and reasons behind these principles simplifies everything. Over time, you just start creating valid HTML and adding ARIA attributes. And to make sure that everything is done correctly, utilities built into the browser help, including Google Lighthouse and Firefox Accessibility Features.

Google Lighthouse is an open-source project for a performance audit, SEO, PWA, and Web Accessibility. It can be used as a service and CI tool built into DevTools. To run, you need to open DevTools, go to the Audits tab and select the audit you want. In our situation, it's Accessibility. In a few seconds, we get the result - an overall score of 0 to 100 and recommendations for improvements. Each recommendation has a specific selector and instructions that need to be changed. Google Lighthouse is also a learning tool because each recommendation has links to Deque University or Google Developers materials that justify the need for change.

google lighthouse accessibility test

Results Google Lighthouse Accessibility Audit for DOU.ua

Accessibility Audits t Google Lighthouse is built using Ax, a toolkit for testing the accessibility of web and Android projects, which has a handy API and can be built into the CI pipeline.

This makes accessibility work a game of points and scores - it is very difficult to stop when you reach 93/100. However, it should be remembered that all these tools are just a bunch of ifs that do not attempt to understand your content. Therefore, I still recommend using your projects and testing them yourself - fill in forms, listen with the help of screensavers. Also, if the budget allows, you can work with professional groups of people with disabilities who test and provide recommendations not only on compliance but also on ease of use. For example, Inclusive IT (this is not advertising - I have nothing to do with the project, but I really like this idea of ​​social entrepreneurship).

Conclusions

Web accessibility is a broad topic that clearly requires more than a few pages. However, in this article, I tried to "infect" my readers with my fascination with assistive technologies and to believe that life can be quality even with trauma or illness. For this, we, as developers, need to remember who we create products for.

Also, for two years I have been presenting this topic at LvivCSS and Uzhhorod Developer Meetup, and I do not hide my pleasure that students develop in accessibility theme, supplement my content and share experience year after year. More and more layout makers not only make colored pages but also check them for accessibility.

Aside from engaging yourself with accessibility, you should also remember to remind designers and businesses alike. In addition to being a more comfortable web for people with disabilities, we will also create comfortable interfaces for ourselves and increase our value in the market.

Useful materials

Udacity/Google Accessibility Course

The A11Y Project  -  Project is a resource with accessibility information and tutorials and recipes for various components.

Web Content Accessibility Guidelines (WCAG) 2.0.

Inclusive Components  - The author implements and explains the recipes of available components.

A11y Cast — YouTube.