Best Practices
Core modules
Access to web content such as public services, education, e-commerce sites, and entertainment is a human right. No one should be excluded based on disability, race, geography, or other human characteristics. This module discusses the best practices and techniques you should learn to make your websites as accessible as possible.
General resources:
Learning outcomes:
Understand the point of accessibility — increased usability for everyone, better SEO, and a wider target audience. Also, be aware of the legal requirements.
Understand that accessibility should be considered from the start of a project, and not bolted on at the end.
Understand the Web Content Accessibility Guidelines (WCAG) conformance criteria.
Use semantic HTML, aka "The right element for the right job", because the browser provides so many built-in accessibility hooks. Good examples are <a> and <input> elements.
Accessible best practices:
Alt text (see also 2.6 Media).
Good link text (see also 2.5 Links).
<label>s for form elements (see also 2.7 Other interactive elements).
Mobile browsers that provide specific usability advantages for specific <input> types such as number or tel.
Making tables accessible with <th>, <thead>, <tbody>, <tfoot>, <caption>, and the scope attribute (See also 2.8 HTML tables).
Using simple plain language, steering clear of slang and abbreviations where possible, and providing definitions where it is not possible.
Understand the purpose of audio transcripts and text tracks (captions, subtitles, etc.) in making audio and video content accessible (we are not expecting mastery in creating them; that is an advanced topic in its own right).
Keyboard accessibility:
Understand why apps need to be keyboard accessible — many people have difficulty using a mouse or other pointing device.
Understand built-in browser keyboard controls.
Understand when accesskey and tabindex are appropriate to use.
Resources:
Learning outcomes:
Text sizing and layout:
Make sure your text is well laid out, consistent, and legible.
Consider providing large-type interfaces for those with visual impairments.
See also 4.1 Text and font styling.
Color contrast:
Use an online tool such as WebAIM's Color Contrast Checker or the TPGi Colour Contrast Analyzer to check whether your color contrast conforms to the relevant WCAG conformance criteria.
Be mindful of those with color blindness or visual impairments; provide high-contrast modes to suit.
:focus and :hover styles:
These are important cues for mouse and keyboard users.
See also 4.2 Styling lists and links.
Sensible animation usage — use animation subtly and provide controls to turn it off:
Consider the needs of those with certain cognitive disabilities.
The prefers-reduced-motion media query was created specifically to help with this.
Best practices for hiding content so that it doesn't become inaccessible. For example, display: none makes content unreadable by screen readers, so it needs to be used carefully.
Resources:
Inclusive design principles, inclusivedesignprinciples.org
Accessibility Design Guide, wiki.mozilla.org (2023)
Learning outcomes:
Understand that there is such a thing as too much JavaScript. A simpler approach is usually more accessible, and often better for everyone.
Understand the value of unobtrusive JavaScript:
If possible, use JavaScript as a usability enhancement, which isn't essential for the app to function.
A good example is client-side validation of form inputs.
Use events sensibly so you don't lock out specific control types. For example, mouse-specific events such as mouseover and mouseout could lock out keyboard or touchscreen users.
Resources:
Learning outcomes:
Screen readers and other assistive technology (AT) types:
Notes:
- The aim here is not to master the usage of all assistive technology types (there are many that we have not listed below), but to be aware of their existence and the types of people who use them, and also to appreciate how and why accessibility best practices work.
- It is also a good idea for web developers to use screen readers or other types of assistive technology, to get an idea of what the web experience is like for users of those technologies.
The importance of source order.
The accessibility layer in browsers, and how assistive technologies hook into it.
Setting up screen readers and using them to test websites on desktop and mobile.
Other assistive technology such as:
Large text or braille keyboards.
Alternative pointing devices such as trackballs, joysticks, and touchpads.
Screen magnifiers.
Voice recognition software.
Switch controls.
Auditing tools such as the Firefox Accessibility Inspector, the ANDI bookmarklet, Wave, and Google Lighthouse accessibility audits.
Resources:
Learning outcomes:
Understand the purpose of WAI-ARIA — to provide semantics to otherwise non-semantic HTML, so that AT users can make sense of the interfaces being presented to them:
The first rule of ARIA: "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so."
In other words, using semantic HTML is an ideal, which is not possible at all times. WAI-ARIA is a bridging technology for such cases.
The basic syntax — roles, properties, and states.
Landmarks and signposting.
Enhancing keyboard accessibility.
Announcing dynamic content updates with live regions.
Resources:
ARIA, Scrimba Course Partner