Development

A well-coded website takes into consideration everyone’s needs, including those with disabilities.

Table of contents

A black and white illustration of a website developer working in front of a variety of devices. There are lines of text on all the screens, indicating code.

Developing an accessible site starts with thinking of the many ways visitors will interact with it.

Make it work.

Everyone is different. We all agree with this statement, but keeping it in mind when developing a website requires diligence. We’re prone to think that if a site’s navigation and layout work for us, they will work for everyone.

To build a site accessible to everyone, we must pay close attention to features that allow visitors to use a mouse, keyboard, touchpad, or assistive device. We also need to think about those who will manage content after the build to ensure the site remains accessible.

Development

Copy

Ensure visitors can view content using various methods and sizes. When setting up responsive breakpoints, account for visitors using a very small screen (think iPhone 4). Allow for the ability to zoom in (and enlarge the text) up to 200% without having to scroll in two directions.

Provide a plain text alternative for text-embedded images (e.g., on graphics and charts). Be sure that site editors have an easy way to manage text alternatives. The ‘figure’ element is a good choice.

Indicate the language of the page using the “lang” global attribute. Include this attribute on elements of pages where language changes.

Development

Buttons/Labels

Ensuring that you assign a ‘button’ element vs. an ‘a’ element correctly is essential. Each element holds specific visitor expectations and functionality and should be used purposefully.

If clear button/link text is not available, it is possible to have the ‘aria-label’ attribute contain more straightforward text based on another field, such as a title. This direction also applies when the content is an icon or you cannot use an alt tag.

Ideally, links should never open in a new window or tab because it can be disorienting. If doing so is unavoidable, provide a visual warning indicator (like this example link to Google), and text for screen readers.

Development

Navigation

Building navigation that works for as many input methods as possible (mouse, keyboards, screen readers, etc.) is critical for web accessibility. This includes navigation in and out of dropdown, expanding, and scrolling menus.

Enable visitors to skip the navigation, so they don’t have to listen to or tab through lists of repetitive content. Accessing site content in more than one way is also helpful (e.g. main navigation + search).

Development

Images

Alternate (alt) text describing website images is critical for those visitors who cannot see them. If the image is for decoration only and without useful information, apply an alt tag regardless. Empty alt tags let screen readers know to skip over the image instead of reading out the source URL, for example.

Make it easy for content editors to input alt text when adding images by building user-friendly CMS fields and elements. Otherwise, content editors will be less likely to use them.

Scalable vector graphics (SVGs) are becoming more common on websites as browsers start to support them. Alt tags don’t work for SVGs and require a plain text alternative.

Development

Data/Charts

Include a plain text alternative when using charts, graphs or other graphic data representations. Having the correct markup will make that content more meaningful. Using elements such as a figure/fig caption helps keep alternative content in context.

Make it easy for content editors to input alternative content by building CMS fields and elements. Otherwise, content editors will be less likely to use them.

Using charting libraries can aid with implementing other visual and keyboard accessibility features such as focusable data points showing additional information and colour alternatives.

Development

Videos & Animation

Include a plain text alternative available to every visitor for audio-only or video-only content.

Provide an easy way for content editors to input alternative content by building user-friendly CMS fields and elements. Otherwise, content editors will be less likely to use them.

Using a video player or embedding option with built-in accessibility features is preferable. Visitors will be familiar with the controls, and it avoids building something that already exists. When looking for an option, ensure it has the following features:

  • Captions and transcripts for audio content
  • Audio description for video content
  • Keyboard and ARIA navigable controls

For animations, using the ‘prefers-reduced-motion’ media query allows visitors with aversions to motion to use the site comfortably.

Development

Forms

Write markup for design elements semantically. Instructions, required fields, field names, field groups and labels have specific elements and attributes that convey the most meaning. You might also consider autocomplete attributes when requesting visitor information.

Include the correct ARIA attributes for the error advisories in the form’s design so that everyone can read and understand them. Methods to prevent errors or make suggestions for correcting them go a helpful step further.

Further reading

Development community resources

The community

External Link

Overlay Fact Sheet

A website dedicated to comprehensive communication on why “accessibility overlays” are not a good fix for inaccessible websites. At best, overlays are redundant; at worst, overlays reduce accessibility.