The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability — Henry & McGee, W3C.
As a front-end developer, I am committed to learning about web accessibility because I want to ensure my web applications are usable for as many people as possible, regardless of ability, context, or situation.
Aside from caring about other people (and my future self), and increasing audience reach, it’s straight-up lawful to learn how to make sites more accessible. Starting 2021 in Ontario, all websites and web content will be required to be fully accessible under Web Content Accessibility Guideline (WCAG) 2.0 Level AA. Failing to meet these guidelines may result in a large fine.
This article outlines some practices to consider when writing code to remove barriers preventing people from interacting with or accessing web content. If you notice I’ve forgotten anything or have any other tips and resources, please comment below :)
color and color contrast
Colors need to have enough contrast to accommodate color blindness or low visibility conditions. WebAIM has an excellent contrast testing tool, where we can input the foreground (i.e. text) and background colors to see if they have sufficient color contrast.
Color shouldn’t be the only method for conveying a interactive element like a link. For instance, if the color blue is the only method for conveying a link, the link would be invisible to those who can’t see blue. It’s better to use an additional visual indicator in addition to the blue, like an underline or a button box.
image descriptors
To enhance user experience for people using screen readers or with slow internet, all non-text content, such as images, charts and graphs need a text equivalent, such as image captions or detailed alt attributes in the image tag.
Within an alt tag, try to describe the picture as you would to someone who can’t see it.
If an image doesn’t add value or isn’t useful to understanding content (i.e. picture is decorative or it is a graph with values discussed completely in the following text), include the alt attribute and leave it empty:
If we don’t include a value for the alt attribute, screen readers know to skip describing the image. If we don’t include an alt attribute at all, the image’s file path will be read instead.
words in images
Include separate HTML text in images instead of images with text within the image file. Other than Alt descriptions, screen readers can’t read the text in images. Also, when images with text are zoomed, they can lose readability and become pixelated.
heading structure
Just as titles with big font sizes help a reader understand the order of the content better, screen readers use heading tags to read content. The screen reader provides an overview of the page by reading each heading in a hierarchical flow. So, pages need proper heading structure to be readable for those who use screen readers to navigate them.
aria
Aria stands for Accessible Rich Internet Applications. It was created to improve the accessibility of applications by providing additional information to screen readers. Additional or more specific attribute information in an element helps assistive technologies provide shortcut keys to navigate through elements defined as landmarks and/or provide a list of all structural elements in the document
Aria role expands HTML semantic vocabulary and defines what an element is or does. A lot of HTML elements already have default roles, so it is intended for roles not available in HTML, for custom elements, or to override default roles. An example of an ARIA role is <form role=“search”>. In HTML, all forms have the same semantics. But with ARIA, we can add to the semantics of a particular form to define it as the search form.
Aria roles can also be used as landmarks. Available landmark roles are banner(title or logo), navigation, main, search, article, complementary(Supporting content for the main content) and contentinfo (informational child content, such as footnotes, copyrights, links to privacy statement, links to preferences, and so on.).
Aria properties define properties for custom elements that cannot be defined in standard HTML. An example is <input aria-required=“true”> This property will cause a screen reader to read this input as being required (meaning the user must complete it).This is not necessary for elements that already have a required attribute, but great for custom elements that do not have them built in.
tab through your site
People with motor disabilities, low-vision or without precise muscle control don’t use mouses, and are dependent on a keyboard to navigate content. So, make sure you can navigate through your site using only the Tab key, and include a focus state on components that are currently selected.
forms
To reiterate the last point, test forms to ensure they can be completed using the Tab key to jump through form controls.
Text labels describe the function of each form control (i.e. text box, check box, radio button, menu etc.). Place the <label> element adjacent to the respective form control. Labels are usually positioned above or to the left of controls, however, the labels for checkboxes and radio buttons are usually to the right of the control.
I know how tempting it is to use placeholder text as labels in forms, but this is a detriment to usability. It’s easy for users to forget what they’re filling in or written once the placeholder label is gone and there is no context. Additionally, placeholder text is hard to read because it’s usually grey and low contrast. In addition, screen readers don’t read Placeholder text at all.
links
i. Users must be able to navigate to and select each link using the keyboard alone. In most browsers, the Tab key allows users to jump from link to link, and the Enter key allows users to select a link.
iii. Tabbing from link to link is a way of skimming web content, especially if users are trying to find a particular section of a web site. Phrases such as “click here”, “view” and “read more” are ambiguous when read out of context.
ii. The main content is not usually the first thing on a web page. Keyboard and screen reader users usually have to wade through a long list of navigation links, sub-lists of links, corporate icons, site searches, and other elements before ever arriving at the main content. We can afford users the ability to skip all that nonsense by adding a “skip navigation” link. Include the link as the first item in the page and add an anchor id at the beginning of the main content, where the link will jump the user to.
In CSS, we never want to “display: none” the skip-navigation link because when an element is set to “display: none”, the screen reader completely ignores it. If you want to hide the skip link off-screen with CSS, you can implement the following code:
javaScript event handlers
To ensure JavaScript event handlers permit keyboard access, use either a device independent event handler (one that works with both the mouse and the keyboard) or implement both mouse dependent and keyboard dependent event handlers.
onMouseOver and onMouseOut requires a mouse. So if the purpose of mouse interaction is not purely cosmetic, and presents additional information or content such as navigation menu, accompany it with an onFocus and onBlur. Both of these event handlers are device independent, meaning that they can be performed with the mouse, keyboard, or other assistive technology. These event handlers are typically used with form elements, such as text fields, radio buttons, and submit buttons, but can also be used with links. onFocus is triggered when the cursor is placed on or within a specific form element, or when a user tabs to the element using the keyboard. onBlur is triggered when the cursor leaves a form element or the user tabs away from it.
The onClick event handler is a device independent event handler when used with keyboard-navigable links or form controls. Most most major browsers and assistive technologies trigger onClick if the Enter key is pressed when the link or control has focus. However, if used with non-link or non-control elements like plain text, table cells, or <div> elements, it’s necessary to detect the Enter and Space key presses while focus is placed on them. There is no device independent or keyboard equivalent to onDblClick, so avoid using it altogether.
limit animations
Animation can make users feel sick if they suffer from vestibular disorders, vertigo, visual processing issues, are hungover, or are motion sensitive for any other reason. So, we should let users decide how they want to interact with our sites: allow them to toggle animation on/off or skip to an end state. Try to reduce motion, popups or unexpected flashes.
For each animation or interaction you’re planning, ask yourself, “If this effect was stronger (much faster, or bouncier, or swoopier), would it be disorienting, or make me feel motion-sick?” If the answer is yes, then you can rest assured there are plenty of people in the world whose threshold is already low enough to be bothered.— Eileen Webb
financial and technical factors
Ensure that content can be viewed on devices of various sizes.
Consider download speeds and order so people who don’t have access to high speed internet can see the information.
more resources
Accessibility Checklists
Chrome extensions
aXe-Coconut is an experimental testing tool that pinpoints issues in code and provides solutions
tota11y aims to helps visualize accessibility violations (and successes), while educating on best practices. It is a single JavaScript file that inserts a small button in the bottom corner of the document. It checks for Alt text and confusing link text, Color contrast, Heading structure, Form labels, Aria landmarks and Js files that places button site
Accessibility Laws in Ontario
Accessibility Ontario offers workshops and webinars for technical as well as non-technical staff. Check out the accessibility training sessions.
More on Aria
This podcast on Aria with web accessibility specialist, Marcy Sutton
