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

<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.

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:

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:

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.

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:

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):

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.

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.