Website Accessibility — Helping the Visually-Impaired See
Imagine for a moment that you’ve lost your ability to see. Think how difficult doing things that were once trivial would suddenly become. Navigating in throughout the world at large would become troublesome enough. But what about, say, using a touch-screen phone? Or using a computer? All of a sudden doing something as simple as paying your utility bill online becomes a task of great difficulty. Forget using a mouse to click on things, you’ve got to get around using your keyboard from here on out. And you’re still going to need to know what part of the website you’re “looking” at, but now you’ll have to rely on specialized software to read the elements on your screen aloud for you to do so. Sounds tough? Well, what if I told you that presence of this functionality is not a given? What if I told you that there are a great deal of websites out there where you can’t even get around using your keyboard? Where the items on the page aren’t even labeled or described in any way?
The American with Disabilities Act, initially focused on preventing discrimination of individuals with disabilities and requiring businesses and organizations to provide accommodations for the physically-impaired, has been reinterpreted in latter years in order to encourage website owners to create functionality that makes it easier for the visually-impaired to traverse their products. In July of 2018, there was a petition signed by 19 Attorneys General addressed to then-United States Attorney General Jeff Sessions to make website accessibility a formally-recognized part of the ADA, which would thus make neglecting website accessibility illegal. In June and July of 2018 alone there were over 150 lawsuits filed against website that failed to provide accommodations for the blind.
As a web developer, not only did I begin to sympathize with those that are visually-impaired, but I also became concerned with how to comply with these possible future regulations. How could I make sure my website could be efficiently used by those with visual-impairments? Furthermore, how could anyone? Fortunately, the answer is quite simple. It comes in the form of ARIA attributes, or Accessible Rich Internet Applications attributes in full, and they could be added directly to your HTML code without the need for any further installation or setup.
Typically HTML elements can be easily accessed by the Tab button. Try pressing the Tab key when on a webpage. Elements such as buttons, links, input fields, maybe even some images can be focused upon quite easily. But things get tricky when elements don’t fall into these categories. Using Javascript, especially in conjunction with web frameworks such as Angular or React, often leads to using <div>’s or <span>’s and imbuing them with important functionality such as navigational elements, or scroll sliders, carousels, ad-hoc tables using flexbox and CSS grid, etc. Left as is, divs and spans cannot be tabbed to, so any div/span elements of your website that require that the user use them to do anything are effectively lost. Seriously, there is absolutely NO way for a visually-impaired user to access these elements without your help. So how can you help? Easy. That div or span? Just add a tabIndex attribute to it, and set it to “0”.
See, the tabIndex attribute dictates what can be focused upon on a webpage when using the Tab key. Items that can tabbed to are items that automatically have a tabIndex equal to 0. These are the aforementioned links, input fields, buttons, etc. Items like divs and spans, by default, have a tabIndex equal to “-1”. Any item with a tabIndex lower than zero is invisible as far as a keyboard-navigating user is concerned. So to make these invisible items visible again, it’s as easy as setting their tabIndex to zero. You can also set their tabIndex to a positive number, say 1 or 2. Items with a higher tabIndex will be focused upon first when that Tab key is pressed, following by those with a lower tabIndex in numerical order (so, for example, pressing Tab will first focus on an item with a tabIndex of 5. Pressing Tab again will focus on an item with a tabIndex of 4. And so on.) But be wary of setting elements with a tabIndex higher than 0. It tends to break the flow of things, having an item that is focused on before the default focusable-items on the page, and you’ll find yourself having to finagle with setting any additional items to the correct tabIndex to ensure the proper order of select-ability (Imagine only setting a link at the bottom of your page to a tabIndex of 5. It’s the first thing that is selected with the user presses tab, then pressing tab again will focus on an element with a tabIndex of zero, like say a navigational link at the top your page. The user is ping-ponging all over the page at this point. It aids in creating confusion.)
Keyboard navigation is a fairly deep topic. There are more things to worry about in using the keyboard to get around than just pressing the Tab key ad-infinitum. More information can be found by clicking here.
With tabIndex accounted for, visually-impaired users can traverse your webpage. But how will they know where they are? They employ the use of a screen reader, which is software that basically dictates what is on-screen. It will read the text on your webpage, and it will read the text on an element that is focused upon, but ONLY IF that element contains text that is supported by said screen reader. If your site is composed of divs and spans, there is no way for a screen reader to know what they consist of unless you specifically tell it what it consists of it. Furthermore, there is no way of knowing WHAT your div or span is supposed to represent. Is it a menu slider meant for scrolling through your page? Or is it a navigational tab meant for going through different sections of the site? Who’s to say? Guess what? You’re to say.
Here’s where ARIA comes into play again. By adding an attribute to your element, ‘aria-role’, you can define what that element is supposed to represent. Is it a slider? Then input ‘slider’ as it’s aria-role. Is it a div that is styled and scripted to function as a button? Then ‘aria-role=“button”’ it up. The screen reader will now tell the visually-impaired user that it is a button they have focused upon.
But what if that button is disabled or hidden from view? ARIA can handle that too. Add an aria-disabled attribute to the element, or an aria-hidden=true to ensure that the user’s screen reader will relay that information properly.
Another, extremely important, functionality of ARIA is allowing you to place descriptive labels upon your elements. By adding an “aria-label” attribute to your element, you can type in text that will be read directly by the screen reader. So if you created a button on your webpage that will charge the user $2.99 when clicked, by all means let that user know by adding a “aria-label=”Click to purchase item for $2.99″” attribute to that item.
ARIA is easy to use and can be added directly to HTML code, whether you’re using a framework or not. Even frameworks such as React support the use of ARIA when using JSX to create components.
More detailed information regarding the use of ARIA roles and labels can be found by clicking here.
If you’re interested in using a screen reader to test how your website comes across to a user who is visually-impaired, you’re best off using JAWS if on Windows, as that is the most extensively used screen reader to date. If on a Mac, Voiceover can be used, and that comes packaged with the OS so there is no installation or purchasing necessary. More frugal Windows users can test with NVDA, which is free with the option of donating.
Website Accessibility — Helping the Visually-Impaired See
Research & References of Website Accessibility — Helping the Visually-Impaired See|A&C Accounting And Tax Services
Source