Developing an accessible website is a constant process that can sometimes require a great deal of expertise. However, there are many concrete steps that most web developers can take to make their sites more accessible to all.
(If you are also a content editor, be sure to review the Big Ideas for Content Editors page in order to gain a full picture of digital accessibility.)
Developing a POUR website
WCAG 2.1 focuses on principles of accessibility rather than just techniques. Focusing on principles is important because one can create a “technically accessible” website that is rather inaccessible.
The four main guiding principles of WCAG 2.1 are:
- Perceivable: Information and user interface components must be presented to users in ways they can perceive. This means that all content is perceivable through sight, hearing, and touch since not everyone has equal use of the same senses.
- Operable: User interface components and navigation must be operable. This means that users must be able to operate the interface using various input methods.
- Understandable: Information and the operation of user interface must be understandable. This means that users must be able to understand the information as well as the operation of the user interface.
- Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance.
These guiding principles can be used to organize the big ideas of developer accessibility.
Perceivable
Semantic markup
To fully understand a document or website, we rely on its structure. Sighted users understand structure at a glance, based largely on visual cues such as the size and position of content. Screen reader users gain that same information from proper labels and semantic structure including headings, lists, and ARIA landmarks.
You can read more about proper use of headings in the content editor big ideas section of our site.
ARIA is a specification that allows one to define roles, states, and properties of user interface components. The use of ARIA landmark roles is simple and provides a great benefit to screen reader users. Landmark roles identify large content areas and are used by screen readers for navigation. When using landmark roles, it’s important that all page content fall under a role to ensure ease of navigation.
Roles are used by simply adding a relevant role attribute to an appropriate container within the HTML mark-up. Once added, screen reader users can quickly jump to that section of the page. The eight roles are:
- role=”banner”
- role=”navigation” (e.g., a menu)
- role=”main” (the main content of the page)
- role=”complementary” (e.g., a sidebar)
- role=”contentinfo” (meta data about the page, usually the footer)
- role=”search”
- role=”form”
- role=”application” (a web application with its own keyboard interface)
If a role is used more than once on a page, the aria-label attribute should also be used in order to distinguish between the two regions.
Input labels and forms
When filling out forms, sighted users rely on visual cues such as position and proximity to figure out which labels go with which fields. For users who are unable to see the form, the relationships between labels and fields must be made within the code.
This is particularly important because screen readers often switch to “Forms Mode” when they encounter a form. Therefore it is critical to include form instructions in ways that can be read aloud.
Provide an accessible label for every control. Give each control a visible text label that explains its purpose. This is best done with an HTML label element associated with the control.
Make sure the label remains visible when the control has focus. Placeholder text provides instructions or an example of the required data inside unedited form fields. While it can be valuable for many users, placeholder text poses many accessibility challenges, particularly if it is the only means of providing a label or description for your field. Assistive technologies, such as screen readers, do not treat placeholder text as labels and may miss it entirely. Additionally, users with cognitive disabilities may become confused when the prompts/examples they were relying on disappears.
Order
According to WCAG 2.1, when content sequence affects its meaning, the correct reading order must be programmatically determined. The order of content in the source code can be changed by the developer to any number of visual presentations with CSS. However, this can easily cause confusion for assistive technology users. Making the DOM order match the visual order ensures that those navigating the site via keyboard, accessing the content with a screen reader, or disabling the CSS are able to access the content in a logical and sequential order.
CAPTCHA
CAPTCHA is a tool to make sure user input has not been generated by a computer/bot. However, common uses of CAPTCHA pose a number of accessibility issues.
Just as we need to ensure that non-text content like images are perceivable via alt text, we need to ensure that the CAPTCHA is perceivable by all people. Providing an alt text is not possible in this scenario, as a bot would be able to access that alt text. Therefore, image-based CAPTCHA cannot be used in an accessible manner.
Because of the inherent accessibility issues, CAPTCHA should only be used when truly necessary. If CAPTCHA is needed, many feel that Google’s reCAPTCHA is the most accessible version available. You can also check out the W3C CAPTCHA Alternatives for other ideas.
Distinguishable
Images of text
Text in an image can’t be changed in appearance (including size and color) which can make it difficult for some people to distinguish the content. In some cases, such as logos, images of text are unavoidable and therefore allowable. In order to ensure that users can change the presentation of text as needed, text should be provided in HTML and styled in CSS whenever possible.
Resize text
People with low vision benefit from the ability to increase text size through a browser rather than relying on a special screen magnifier. While the scaling of content is primarily a browser’s responsibility, the developer’s responsibility is to create Web content that does not prevent the browser from scaling the content effectively. WCAG 2.1 requires that content be scalable by up to 200%.
Operable
Timing
Time limits need to be adjustable. Because all users require different amounts of time to read and use content, they need to be able to adjust and maintain control. If your content has a time limit, users need to be able to turn off, adjust, or extend that time limit on their own. Exceptions to this rule are when it is real-time event that has time limits built into it (such as an auction) or when the time limit is an essential part of the activity and stopping/extending the time would invalidate that activity.
Ability to stop, pause, or hide moving or auto-updating content. It is not unusual to create webpages with slideshows/carousels that move through their content automatically or videos that begin to play automatically. While this works well and is engaging for some users, others find it distracting and difficult to focus on other essential content on the page. Therefore, there must be a prominent means for pausing the display. The ability to pause must also be keyboard accessible.
Keyboard accessible
Many people with disabilities use a keyboard rather than a mouse to navigate on their computer. Because of this, we must build websites and create documents that can be easily navigated using a keyboard.
There are several primary techniques that allow for better keyboard navigation:
- Focus - When an item has keyboard "focus", it can be activated or manipulated with the keyboard. Visual focus allows the keyboard user to see quickly and easily on their screen which element has their focus.
- Order – Because keyboard users tab through the content on a site or document, we must ensure that content on the page is in the intended order when tabbing.
- Skip to main content – Most webpages have lengthy top-level navigation that can be tedious to tab through after each new page is visited. By providing a “skip to main content” link, keyboard users can bypass the navigation at the top of each page and dive right into the main content.
- Shortcut keys – Whenever possible, avoid coding shortcut and access keys. If you must use shortcuts, ensure that they do not conflict with common browser and screen reader shortcuts.
- Keyboard traps - Ensure that keyboard focus is never locked or trapped on a page element. The user should be able to navigate to and from all page elements using only the keyboard.
Flashes
Content should not be designed in a way that is known to cause seizures. Generally this means that content should not flash more than 3 times in any one second period.
Page Title
In order to help users find content and orient themselves within it, it’s important to include a descriptive title for all web pages.
Understandable
Readable
Language - The language of both the page and any of its parts should be programmatically determined to ensure that browsers are able to correctly present content written in multiple languages.
Reading level – Content should be written as clearly and simply as possible (8th or 9th grade level). The readability of content can be determined by applying a readability formula to the selected passage.
Consistent Navigation
Using consistent navigation and layout on your pages makes it easier for users locate specific information or functionality. While this helps everyone, this is especially important for users with low vision who use screen magnification.
Error notification
Even with the best designed forms, we can expect users to make mistakes, so it is essential that users receive necessary information to prevent and/or correct those mistakes. The error message should be as specific as possible and must be presented in text (not just through color). This ensures that those who are blind or colorblind will be able to quickly and easily perceive that an error has occurred.
Robust
At the heart of the concept of a website being “robust” is that users should be able to choose their own technologies (including various browsers and assistive technology) to access web content. In order to ensure that this is possible, one must create web content that validates against the technical standards for the technologies being used. Valid HTML is much more likely to work correctly across browsers and platforms than sloppy HTML.