The value of accessibility

What if I told you web designers out there that there are people who might visit your website that don’t care what it looks like?

Visually impaired people navigate the web for the same reasons we all do, to find information, to shop and to perform a myriad of important tasks using web-based applications. But visually impaired people experience the web differently and we need to be sensitive to their needs when we design and build websites.

According to the U.S. Census Bureau and the U.N. and World Bank over 47 million Americans, and up to 650 million people worldwide, have some kind of disability. Every visitor to the sites you design needs to be able to find the information they are looking for and perform the tasks they intended to perform regardless of what the web page or app looks like. A lot of different factors that go into the creation of the web page or application can impact accessibility.

You take the blue pill–the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill–you stay in Wonderland, and I show you how deep the rabbit hole goes. — The Matrix

Are you ready to go down the accessibility rabbit hold with me? We will need to dive into to the technical aspects of web pages. HTML is the skeleton of a webpage while CSS, JavaScript and images enhance the HTML. Often times visually impaired people miss out on all these enhancements. Although accessibility is mainly a developer task, sometimes the technical requirements required to preserve or enhance accessibility will affect the appearance of the website. That means that design, copy, user experience and development all need to collaborate to make sure that navigation controls, forms, buttons, headings, buttons, links, and more are accessible.

People who are blind, visually impaired, illiterate or learning disabled use assistive technologies to navigate the Internet. Screen readers are the most common assistive technology for the web, these software programs attempt to interpret what is displayed on the web page and convey it to the user, usually through converting the text to speech but sometimes through a Braille output device. Screen magnifiers are also often used in conjunction with a screen reader. Typically a screen reader will attempt to parse the HTML from the top of the HTML file to the bottom and speak relevant elements to the user. Ideally the screen reader will allow the user to successfully move a virtual cursor down the page in order to fill out form fields, click buttons and make selections from drop-down menus and other controls.

To test thoroughly for accessibility you’ll need to ensure that the website or app performs well on each of the many screen readers available. There are several popular free and/or open source screen readers on each platform including JAWS, and NVDA. Microsoft users can use NVDA, while Apple computers and iOS devices come with Voice Over which can magnify keyboard controls and read screen contents, and for Unix devices there’s Orca. The Chrome browser has two assistive technology plugins, ChromeVox for screen reading and ChromeVis for magnification.

Most web accessibility problems occur when the screen reader’s virtual cursor becomes trapped in a poorly designed form or skips over an important control or an important piece of textual information. Verifying that websites are indeed usable is similar to browser testing because each screen reader has different requirements and limitations. This is why understanding the behavior of each screen-reader is important. The needs of various screen readers can be accommodated by adding various special HTML tags to the important elements of the page.

Modern dynamic web UI can be particularly problematic for accessibility because important elements are added to the page dynamically using JavaScript. Custom drop-down menus, modals, tooltips, accordion content and dynamic errors and notifications can be challenging for screen reader users to understand because of a communication breakdown between the HTML, JavaScript and the screen reader. Native HTML and JavaScript have no way to communicate page (Document Object Model) updates to the screen readers. Developers need to move “focus” (the screen reader’s virtual cursor) to the part of the UI that changed. When a modal opens up developers need to put the user’s focus on that modal so that the screen reader can read that content and the user can understand and interact with it.

This is done through the use of special HTML tags called WAI-ARIA tags. WAI-ARIA (Accessible Rich Internet Applications) can bridge the gaps between what the raw HTML of the page says and what sighted users see by providing a standardized way for developers to add extra meaning to states, properties, relationships, roles and live regions that a screen reader otherwise would not understand.  Developers can use aria-level to explain to screen readers the hierarchy of each heading on the page. With aria-label developers can add a heading to describe the purpose of a discrete element on the page. This helps developers create clear relationships between different elements. Developers can also draw attention to important controls by labeling them with aria-role tags, for example a drop-down menu button would be labeled with the following tag: Aria-has popup: true.

See the Pen Simple Accessible Tabs by Scott Vinkle (@svinkle) on CodePen.

In the HTML in the example above the tabs are created using an unordered list with classes on each list item. The jQuery captures the click events when a tab is clicked and adds ‘aria-selected’ : ‘true’ and ‘tab-widget__tab-content—active’ to the selected tab and hides the other tabs by adding ‘aria-selected’ : ‘false’ to the remaining tabs. On line 127 the initial attributes for the tabs are set, together these snippets help screen readers recognize which tab is visible. The JavaScript on line 35 also adds keyboard support to the tabs. The rest of the file handles capturing click and keyboard events so that jQuery can add ‘role’ and ‘presentation’ attributes to the currently selected tab.

Aria tags can help screen readers to interpret custom controls as radio buttons when the custom control is labeled with: Aria-role=radio button. When an application has a sandbox area that communicates feedback or updates to the user it can be labeled with a live region tag: Aria-live. This ensures that when the text on this element changes it will automatically be spoken to the user through the screen reader.

Page refreshes are a key part of the web for screen readers because when a page refresh occurs it signals to the screen reader that it should announce the new page to the user and re-read the contents of the page to the user. This means that single page web applications pose special challenges to accessibility. In a single page app there no full page refreshes so the screen reader and therefore the user will not be alerted to the updated content. The result will be that the user receives no feedback on their actions. The best solution is to emulate native page refresh behavior. On view loaded, update the page title and announce it to the user.

The full specifications for WAI-ARIA are maintained by the W3 like the specifications for HTML itself under the Web Accessibility Initiative (WAI) but sometimes guidelines can be more helpful than specifications so here are a few general guidelines for designers:

• make sure that there is visual contrast between text and its background.
• don’t use color alone to convey information;
• provide your website with clear and consistent navigation;
• ensure that form elements clearly include associated labels;
• make sure that feedback elements like error messages can easily be identified;
• use headings and spacing to group related content;
• provide alternate text for images;
• consider designing your website so that all functionality is accessible through the keyboard.

There are several simple decisions you can make when developing a website that will make the website more accessible without getting too deep in special accessibility markup or screen reader testing. By making sure that your HTML conveys meaning through its structure you will help screen readers process information in the same way it appears on the page for sighted users. This is important for users who use a magnifier in conjunction with a screen reader.

Using appropriate HTML mark-up for headings, lists, tables, and other elements allows the screen reader to categorize the structure of the page for the user in a familiar way. For more involved layouts HTML5 provides additional elements, such as <nav> and <aside> to make content easier for screen reader users to understand. Even writers and content strategists can have a positive impact on accessibility. By providing unique page titles for each page, and by using headings to convey the meaning and structure of each web page. Make sure that the link text you write is meaningful outside of the visual context of the page (avoid writing calls to action like “click here”). Write transcripts and captions for multimedia content.

We have gone very far down this rabbit hole together because the potential beneficiaries of all this work are a wider group than you might think. If you’ve ever tried to use a mobile app with one hand because your other hand is carrying something, if you have ever tried to use a mouse with your non-dominate hand because of an injury you’ve been situationally disabled. And isn’t it wonderful when your fingers are sticky and you can still navigate a website using a keyboard with your knuckles? All of us unfortunately are susceptible to the disabilities that come from getting older like memory loss, hard-of-hearing, deteriorating vision and limited movement. 

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect. — Tim Berners-Lee, W3C Director and inventor of the World Wide Web

Featured image, accessibility image via Shutterstock.