Accessibility
Accessibility is for everyone.
What if the work really did only impact those with disabilities? What if the work was only for those who are blind or deaf? What if the work were only so that one person could use their iPhone? I should hope we’d be doing it anyway.[7]
Getting Started
Learn about some quick ways you can make your website more accessible on hidde.blog[38,39].
Use this checklist to ensure you are doing your best to meet accessibility requirements. Consult best practices[5] for those with low-bandwidth internet.
Contrast
There needs to be a contrast of at LEAST 4.5:1 between the background and foreground of colors for readability.
In WCAG 2, contrast is a measure of the difference in perceived "luminance" or brightness between two colors (the phrase "color contrast" is never used). This brightness difference is expressed as a ratio ranging from 1:1 (e.g. white on white) to 21:1 (e.g., black on a white).
Alt Text, Titles, and Captions in HTML[11-14, 35-37]
Alternative (Alt) Text is meant to convey the “why” of the image as it relates to the content of a document or webpage.[11]
- Add alt text to all non-decorative images.
- Keep it short and descriptive, like a tweet.
- Don’t include “image of” or “photo of”.
- Leave alt text blank if the image is purely decorative
- It's not necessary to add text in the Title field.
Accessibility and HTML Elements
You can go a long way by just using the correct semantic elements. If it's a link, use an a
tag, if it's a form, use the form
tag, etc.
Tab Order
Only interactive elements should be tabbable! Tab is a special key used with screen readers, it should not be used for everything.
The tab order is set by how they show up in the DOM. If you want users to be able to tab through something in a certain order, you should put the elements in the HTML in that order. The keyboard focus should also visually make sense. When looking at the page as a user, does tabbing through make sense, or is it jumping around in unexpected ways?
You can set the tabindex
attribute on an element if you must, but it is strongly discouraged and should be avoided if at all possible.
tabindex
Ordering[32]
tabindex
with values of 0
and -1
are special cases:
tabindex="0" means that the element should be focusable in sequential keyboard navigation, after any positive tabindex values. The focus navigation order of these elements is defined by their order in the document source.
A negative value (the exact negative value doesn't actually matter, usually tabindex="-1") means that the element is not reachable via sequential keyboard navigation. tabindex="-1" may be useful for elements that should not be navigated to directly using the Tab key, but need to have keyboard focus set to them. Examples include an off-screen modal window that should be focused when it comes into view, or a form submission error message that should be immediately focused when an errant form is submitted.
tabindex
should be equal to or less than zero, NEVER above.
Warning: You are recommended to only use 0 and -1 as tabindex values. Avoid using tabindex values greater than 0 and CSS properties that can change the order of focusable HTML elements (Ordering flex items). Doing so makes it difficult for people who rely on using keyboard for navigation or assistive technology to navigate and operate page content. Instead, write the document with the elements in a logical sequence.
Elements with tabindex="-1"
can still be focused on using Javascript via .focus()
, but again this should be avoided if at all possible.
Interactive Elements
The browser will handle the user interaction natively and assistive tech will give special options for interactive elements.
a
tags with anhref
, or elements with arole="link"
button
, or elements with arole="button"
form
andinput
elements (and all related, like checkboxes, etc.)
Often time, people use div
s and span
s to build custom buttons and things. They will not be focusable by default or interactive in the way that assistive tech users expect! This must be added manually via giving a tabindex
[32], having a proper role
, and adding event handlers for their equivalent keyboard interactions.
SPAs
SPAs made with a framework like React put out standard HTML and thus should follow the same rules of accessibility for static sites. Be careful that you are using semantically correct HTML whenever possible and giving correct aria
attributes when necessary.
Focus and Title
In traditional/static websites, when moving to a different page (for instance, after following a link or submitting a form):
- focus is placed at the start of the page
- if running a screen reader, the title of the new page is announced
- generally, the screen reader starts reading the content of the page from the top
If you have a single page application, these must be done explicitly, as dynamic content is being added/removed dynamically and no "new page" is being moved to in the eyes of the browser. When moving to a new page, you should ensure that:
- the title is updated
- focus is moved to an appropriate place, like that start of the page or the
h1
element
Custom Components
If you are building custom components for the web, follow the ARIA Authoring Practices Guide[x] to make sure you are giving all users everything they need.
References
- https://webaim.org/resources/contrastchecker/
- https://webaim.org/articles/contrast/
- https://www.a11yproject.com/checklist/
- https://www.w3.org/WAI/test-evaluate/#tools
- https://seirdy.one/2020/11/23/website-best-practices.html
- https://hidde.blog/more-common-a11y-issues/
- https://sommerpanage.com/posts/2022-09-16-a11y_for_everyone/
- https://testingaccessibility.com/
- https://randoma11y.com/
- Make your website accessible and look ok
- https://accessibility.huit.harvard.edu/describe-content-images
- https://gomakethings.com/how-to-write-good-alt-text/
- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure
- https://gomakethings.com/a-case-study-in-alt-text/
- https://daisy.org/news-events/articles/art-science-describing-images-w/
- https://inclusivepublishing.org/blog/the-art-and-science-of-describing-images-part-two-w/
- https://inclusivepublishing.org/blog/the-art-and-science-of-describing-images-part-three-w/
- https://www.smashingmagazine.com/2021/03/complete-guide-accessible-front-end-components/
- https://hidde.blog/keyboard-shortcuts/
- https://www.w3.org/WAI/WCAG21/quickref/?versions=2.1#character-key-shortcuts
- Best practices for making things work on older browsers
- Atlassian Design's Accessibility Guides
- Accessible contrast finder
- ARIA Spec for the Uninitiated, video
- W3C HTML Validator
- Derek Featherstone on LinkedIn, and his homepage
- Accessible Frontend Components
- Understanding the Four Principles of Accessibility
- The 7 Principles of Universal Design
- Chrome Axe DevTools
- WebAIM's Guide to Conforming to WCAG2, successor to Section 508
- tabindex
- Focusability and tabbability of all elements
- ARIA Authoring Practices Guide
- Axess Lab | Alt-texts: The Ultimate Guide
- Considerations when writing alt text | by Scott Vinkle | Shopify UX
- WebAIM: Alternative Text
- Common accessibility issues that you can fix today | hidde.blog
- More common accessibility issues that you can fix today | hidde.blog
- A New Day: Making a Better Calendar - 24 Accessibility
Last modified: 202304260456