What is Accessibility?

Accessibility or A11Y for short, in its simplest terms, means making the content and functionality of a website or app available by anyone regardless of disabilities. When most people think of a disability, they think of someone with a permanent medical condition such as blindness or other physical condition that limits their motor or cognitive abilities. While that view is true, there are other types of disabilities that we should consider when creating software products. An individual can have a visual, motor, hearing or cognitive disability. These disabilities can be further categorized into situational, temporary or permanent. When we develop software, we have to consider individuals with permanent disabilities as well as those with temporary ones like a broken arm or situational disabilities like sitting at a café with the sun shining on their screen

Web Content Accessibility Guidelines

The Web Content Accessibility Guidelines (WCAG) was put together by the World Wide Web Consortium(W3C) as a list of best practices to provide a methodical way for developers to implement accessibility on the web.  These guidelines were taken by the Web Accessibility in Mind (WebAIM) group and turned into a checklist to use during the development process. WCAG is based on the following four principles:

• Perceivable: Web Content is made available to the senses – sight, hearing, and/or touch.
• Operable: Interface forms, controls, and navigation are operable with different forms of input devices.
• Understandable: Information and the operating of the user interface must be understandable.
• Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents including assistive technologies.

Accessibility during development

Focus

The simplest place to start with accessibility is by looking at an element’s focus state. All interactive elements such as links, buttons and form controls, as well as custom interactive components, should have a focus state. You can see an element’s focus state by using the tab key on the keyboard. Different browsers style the focus state differently. Firefox uses a dotted border while Chrome adds an outline around focusable elements. It is possible to remove the browser’s default focus styles with the outline CSS property, but make sure to always add a custom visual state with the CSS sudo-class :focus when you do so.

Order

Browsers organize elements on a page into the Document Object Model (DOM).  The browser takes all the elements rendered on a page and it creates a nested tree-like JavaScript Object, the DOM, in the browser’s memory. This object is used to determine the order in which elements receive focus while using the tab key on the keyboard or other assistive technologies. It is possible to change the visual order of elements with CSS by changing the float property or positioning an element at an absolute location on the page. Keep this in mind when changing the visual order of elements. In the example below the first set of buttons are in the same order as the DOM tree, while the second set uses CSS to change the position of the first button. When developing you want to keep the visual order and the focus order the same to avoid confusing those using the keyboard or other assistive technology to access the application.

Tabindex

The browser provides a default tab order base on the DOM tree for native interactive HTML elements. There are cases when it is desired to change, remove, or prioritize the order. This is useful especially with custom components that may use non-focusable elements in their implementation. For that purpose, the tabindex attribute can be used on any element that otherwise would be ignored by the focus order. Adding tabindex=”0” to any element will cause it to take on the natural focus order in the DOM. tabindex=”-1” removes an element from the natural focus order and causes it to be skipped. Both are useful when creating custom components such as a select menu or a button that uses non-focusable elements like [divs]. It is possible to add a tab index number greater than 0 causing the element to jump to the front of the focus order, but this is considered an anti-pattern and should not be done.

Semantics & ARIA

Many elements give meaning to the layout of a page. It is important to use these elements because they help assistive technologies like screen readers communicate to users the structure of the page or the purpose of a piece of content.

Headings

Use the proper hierarchy when using heading tags (H1, H2, H3, H4, H5, H6). Visually making text bold may be helpful for most users, but it provides no meaning to the page. Think about these as a list of related groups like a table of contents. Based on this structure, you should be able to identify sections and sub-sections within the page. Normally there is only one H1 heading on a page and all the sub-sections would follow the perspective hierarchy. Heading on sections of the page help users and screen readers quickly identify the purpose of the section. Studies have shown that people scan a page rather than reading line-by-line. Once they find something of interest, they narrow down the focus to the details of the content. Use headings to identify your sections.

HTML5 Semantic elements

HTML5 introduced a new set of elements that behave exactly like a [div] does. They are block level elements that add no style but introduced meaning to the content they hold. Use these elements instead of a [div] when appropriate to communicate content meaning within a page or components: header, footer, nav, article, section, main, aside.

Examples of using semantic native elements include using tables to display tabular data instead of implementing a layout Use the <p> element for regular body text, an <a> element for links and a <button> element for buttons. Many of these have a special meaning for assistive technologies but also include default accessibility functionality. One simple practice is to never leave an <a> element without the href attribute because it changes how it is accessed with the keyboard. It is a better practice to use a button if there is no link and style the button with CSS if you need it to look different.

Link and button text

The text used for links and buttons should be descriptive to help people with accessibility technologies better understand what they will be doing when they click them. It is clearer for everyone to use the following text for a link; “click here to learn about accessibility” than to simply use “click here to learn about accessibility”. It would be even better to omit the “click here” text altogether and use “learn about accessibility” on its own. A screen reader would not tell a user what to expect if they click the link reading “click me”. You can also use the ARIA specifications to add meaning or change labels for screen readers and other forms of accessibility technology. It is specifically helpful for buttons and other form controls. We will cover this further in a bit.

The Accessibility Tree

Screen readers build an accessibility tree to help users make sense of a web page. The accessibility tree is similar to the DOM tree except that it takes the semantics elements and allows the user to sort, skip, or jump to different elements such as links or buttons on the page. Important elements are also known as landmark elements.

New frameworks like React and Angular have allowed developers to create custom components that don’t have the same semantic meaning as some of the native elements. To solve this problem the Web Accessibility Initiative’s Accessible Rich Internet Applications specification (WAI-ARIA or just ARIA) was created.  It allows developers to use a set of predefined attributes that modify the way an element is translated into the accessibility tree. This is great for custom components because developers can use elements without meaning like the [div] to create rich interactive components and still make them accessible through screen readers or other assistive technology. It also allows you to change the meaning or add better descriptions or labels for accessibility tools.

ARIA

The ARIA specification provides a set of attributes that allow developers of accessible rich internet applications to provide screen readers with information so that they can properly interpret the elements. Examples of these include the role and the aria-label attribute. role could be used when creating a custom checkbox, slider or dialog. Assigning the attribute role=”checkbox” would communicate to screen readers the purpose of the component. [aria-label] allows developers to add a string that is used to describe an element but has no visual impact. Think of a button or link with only one word as its label text. aria-label allows you to override the text description for screen readers without changing the visual label. You may have seen these attributes in the source code of component libraries. I will not cover the ARIA specifications here; the basics alone warrant its own article. Be aware that you can use it to add meaning to your application and help make it accessible to users that depend on screen readers.

Styles, Color, and Contrast

When styling elements ensure that all interactive elements have a focus style. If the company’s branding is different from the browser’s default focus styles, ensure that a custom focus style is provided.

Beyond interactive elements do not depend solely on color to communicate element status or purpose. Red text color is great to display an error message to most users, but someone who is colorblind may not know it is an error. The same is true for someone using assistive technology to access the application. The ARIA specification can help you add meaning to these types of components and make the application accessible to a wider range of people.

Similar to color blindness, there is also a part of the population that has low contrast vision. They are not able to easily see elements or text with low contrast. When selecting a color pallet, select colors with enough contrast between the foreground and the background for people with such a condition to see it. Contrast is also an issue depending on lighting conditions. This would be an example of a situational temporary disability. Think of the earlier example of the person sitting next to a sunny window.

Responsive Web Design

Last but not least, there is Responsive Web Design (RWD). HTML5 and CSS3 made it possible to create web pages that resize and adapt the layout based on the size of the screen the user is on. RWD makes applications accessible across different devices without the need for separate source codes. This is great for reducing business costs, improve the user experience, and speed up the delivery of features across multiple devices. Avoid using tables to create the layout. Tables are meant to display tabular data.

Conclusion

Making applications accessible is not a complicated process, but it is one that has to be done with purpose. Accessibly like the user experience, is about empathy for the limitations that users face while using the software we create. Those limitations can be visual, motor, hearing or cognitive and furthermore they can also be situational, temporary or permanent. Accessibility solutions should follow the WCAG list. An interface’s accessibility can be judged by asking if the feature is perceivable, operable, understandable, and robust. These are the four principles WCAG is based on.

When implementing a feature use the following checklist to test it for accessibility:

1. Ensure interactive elements are accessible without a mouse and with a screen reader. You can use a screen reader plugin on your browser to get an idea of how someone would be able to use our software with it.
2. When an interactive element is in focus, make sure visually the styles change and it is obvious what is in focus.
3. Maintain the visual and focus order of elements the same.
4. Use native semantic elements for content and use the HTML5 semantic elements where appropriate.
5. When creating custom components use the ARIA attributes to make these elements accessible to screen readers.
6. Don’t rely solely on color to communicate meaning and make sure that colors have enough contrast.
7. Test the application on different screen sizes, make sure that it is still accessible on different devices.