General guidelines for making an accessible web page
I spent a few days watching Udacity’s accessibility course by Google to get a handle on basic accessibility techniques. It turns out that accessibility isn’t as daunting as it might sound. This article summarizes what I learned from this course. The goal is to teach web developers accessibility techniques when creating a new feature or product.
FYI Udacity’s course uses the following assistive technologies for its demos:
- ChromeVox
- Mac OS VoiceOver
Both of these tools are screen readers for users with sight impairments.
For additional reading on accessibility you can check out the following resources:
Create good page structure with correct use of elements and DOM order.
Use landmark elements.
Landmark elements like header, nav, and footer are more useful to screen reader users because they define regions of a page. It’s best to use these instead of divs which have no native semantics.
Below is a graphic that labels several HTML5 landmark elements you can use to structure your pages. For more about these, check out Lesson 4 “Navigating Content,” Concept 10 “Landmarks” in the Udacity course.
Use elements that are focusable.
Right out of the box, native form elements, buttons, and anchors are focusable by keyboards, and keyboards can interact with them to provide input or perform an action. These elements are also automatically added to a page’s tab order. If you use non-focusable elements in place of these, you’ll have to add semantics and tabindex in your DOM as well as functionality so that keyboards can interact with them.
Arrange your focusable elements in a logical tab order.
The tab order of your elements will, and should, follow the order they appear in your DOM, so try to avoid using CSS that changes the visual order in which they appear. Otherwise, the focus styles might jump around the screen during tabbing. This will cause a confusing experience for mobility-challenged people using keyboards.
Below is an example that demonstrates this unexpected behavior. The “I’m first!” button will receive focus before the other two because it is first in the DOM.
Use heading tags in their logical order.
Creating a logical page structure includes using heading tags (h1, h2, h3, h4, h5, and h6) properly. Don’t use a heading tag simply because of its style. Your heading tags should follow in their natural hierarchical order. This way a screen reader user will understand the subsections within a section. You can use CSS to style your headings as you like.
Use anchor tags when appropriate and as intended.
Since some assistive technologies allow users to browse through all links on a page, using anchor tags with an href attribute and a valid value will make them accessible to the user.
The following are common anti-patterns developers use to present actionable text on their web pages (They should be avoided.):
1. Using an anchor tag, or a span styled as a link, with scripting to perform an action when the element is clicked.
In this example the span and anchor are not actionable with a keyboard. Try using a button as an alternative.
2. Using an anchor tag with a non-sensical href value plus scripting to perform an action.
In this example having a value of “#” for the anchor’s href attribute doesn’t make the anchor actionable by a keyboard. It’s best to replace the anchor with a button element.
3. Using an img element as link content.
The first example works for sighted users, but the image will not be available to assistive technologies. To fix it, add an alt attribute with a description of the image.
Do not remove focus styles from focusable elements.
A browser’s default focus styles are extremely important to users who use a keyboard to navigate a page. Focus styles visually indicate which interactive element is ready for input, and they also tell the user where he currently is in the page structure.
For many websites a browser’s default focus style doesn’t fit with the site’s design. Focus styles are easily customizable with CSS using the :focus pseudo-class. The course provides good tips on re-writing those styles.
Write helpful link text.
Text that is hyperlinked should be written in a way that describes the purpose of the link. The following examples demonstrate this:
- This website uses cookies to ensure you get the best experience on our website. For more information, see our cookie policy.
- Subscribe to our newsletter to get weekly updates in your inbox.
The following are examples of commonly used link strings that are considered an anti-pattern to accessibility (i.e. Don’t use these.):
- Learn more
- Read more
- Click here
Write helpful alt text for images.
A screen reader will read aloud the alt text for an image, so the text needs to describe what’s going on in the image in its given context. If there is no alt attribute, the image will be handled in different ways depending on which screen reader is being using. According to Oomph’s accessibility article (published January 25, 2019), JAWS will announce “blank,” and NVDA will announce nothing. VoiceOver will announce “unlabeled image.”
The screenshot below shows VoiceOver announcing and displaying the alt text associated with the teacup image.
If an image is deemed redundant, you can add an alt attribute to the image but with an empty value. This will remove the image from the screen reader’s accessibility DOM tree; therefore, the screen reader will not announce it.
Make your site responsive, and use relative units.
There are a number of reasons why developers should make their sites responsive with a mobile friendly layout. One of those reasons is that if a user zooms into a web page, the layout will at some point switch to the page’s mobile design. This is helpful because as the page content gets bigger, the mobile design will re-align the page sections for easier browsing and scrolling.
Relative units for font sizes and width, and in some cases margin and padding, are also very important. They allow the text size to increase if the user changes the browser’s font settings, and your page elements will scale accordingly. Below are examples of how two sites change with page zoom. The first one shows the W3C’s page adjusting to its mobile design where content is stacked. The next one shows that Wikipedia’s site does increase font size, but the layout doesn’t change. The welcome banner extends beyond the viewport, and the two-column layout, though still readable, is a little cramped.
Make sure your site meets the minimum contrast requirements.
The WCAG requires that your text, images, and other components provide a minimum amount of contrast against your chosen background color. You can test your UI’s contrast at WebAIM’s Contrast Checker.
Do not convey information with color alone.
Consider the form below. It does not display error messages if the user submits an invalid value. Instead, it uses color to indicate the error.
In this example the phone number is invalid because it’s missing an area code. Both colorblind and screen reader users can have an issue with this. The red line alone does not sufficiently tell those users there is a problem. To remedy this, you should add text that explains the error.
You can use the NoCoffee Chrome extension to simulate different visual impairments and determine how you can improve your UI.
Use the right role and ARIA attributes on elements without native semantics.
In some cases you might need to forgo the use of focusable elements (such as input, select, or button) and instead use divs or spans to create new stylized components. The first thing to do is assign a role to the component’s main element. The WAI-ARIA spec lists role descriptions that you can browse and determine which best suits your component.
If you click on any of the listed roles, you’ll find more information and a table of associated ARIA attributes, some of which are required. It’s best to watch Lesson 5 “ARIA” to get a general grasp of this topic. In addition to adding role and ARIA attributes, you might need to programmatically add keyboard functionality to your component. Adding role and ARIA attributes alone does not make a component fully accessible.
Helpful ARIA resources:
Wrap up
In summary there are two overarching lessons in accessibility:
- You can achieve accessibility on your site by using standard web development practices that you already know.
- If you can’t use natively focusable elements, you must use the role attribute plus any required ARIA attributes and extra functionality to make your custom component accessible.
