Website Accessibility — Helping the Visually-Impaired See

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.

It should be noted that, since the HTML5, using a plain ‘disabled’ attribute gets the job done just the same.

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.

Further ReadingExtensive information regarding the deeper functionality of ARIA can be located here: https://w3c.

github.

io/using-aria/More info on screen readers: https://webaccess.

berkeley.

edu/ask-pecan/what-is-a-screen-readerMore info on ADA: https://www.

boia.

org/blog/ada-and-accessibility-compliance-whats-new-in-2018https://www.

boia.

org/blog/attorneys-general-urge-action-and-clarity-from-jeff-sessions-doj-on-web-accessibility.. More details

Leave a Reply