Web Accessibility: Keeping in Check
In my last blog post, I wrote about the no-man’s land that developers find themselves in with regard to web accessibility regulation. By and large we are left to regulate ourselves, and tight deadlines or limited budgets sometimes mean that accessibility doesn’t get the attention it deserves. To ensure that accessibility isn’t merely an afterthought, I’ve identified some questions to ask myself during each stage of the front-end development process. While not an exhaustive rundown on accessibility measures, answering “yes” to the questions below will give people with disabilities a much better user experience.
When writing HTML:
1. Is my HTML semantic?
It is rare for anyone to sit down and read a webpage straight through, top to bottom, as if it were a page in a book. Our eyes dart around the page, scanning the navigation section and sub-headers before deciding where to focus our attention. Screen readers attempt to parse HTML to offer a similar page preview to users, but that is possible only if our HTML tags are semantic — in other words, if they have meaning. The purpose of header tags, for example, isn’t just to display different text sizes, it is to indicate relative importance. So even though design mockups almost never reflect the default styling of an
<h2>, etc., we should not give in to the temptation to discard those tags in favor of classes. If our headers are nothing but styled
<span> tags, we’d better hope that the information that a blind user is seeking isn’t a dozen paragraphs down the page! Similarly, HTML5 tags like
<footer> provide valuable information to screen readers.
How to check: An easy way to check your header tags is the “Web Developer” plugin for Firefox — the “View Document Outline” will let you see whether your header tags display a meaningful hierarchy. WAVE (Web Accessibility Evaluator) is helpful for seeing where HTML5 elements are used and flagging problematic HTML.
2. Have I included helpful alt tags for every non-decorative image?
Alt tags are text that is read aloud in place of images. Alt tags are an obvious measure to improve accessibility, but they are easily missed on sites with numerous images. Furthermore, just having an alt tag isn’t enough — they must be descriptive. When writing alt tags, put yourself in the user’s shoes: if you were seeking information contained in a complex flowchart, would
alt="flowchart-image" be helpful, or would it just make you want to chuck your computer out the window?
How to check: Run your HTML through a validator. The Firefox plugin mentioned above also lets you view your actual alt text above each image.
When writing CSS:
3. Are my links and buttons large enough?
We’ve all “fat-fingered” buttons before, and small “tap targets” — buttons, form fields, and links — are even more problematic for people with motor impairments. Microsoft recommends a minimum size of 40 pixels for buttons on mobile. Google recommends even larger (48px), plus as a minimum 32px spacing between targets. While clickable items on a desktop don’t need to be quite so large, keep in mind that precisely positioning a cursor is also challenging for some.
4. Is my text large enough and easy to resize?
Text that is smaller than 16px is hard for many people to read. Additionally, text should also be resizable by the user without breaking the page layout: the WAC guidelines recommend ensuring that text can be enlarged up to 200% “without loss of content or functionality.” This requires that the surrounding layout adjust to the larger text, without text overlapping, cutting off, or requiring annoying horizontal scrolling.
How to check: In Chrome, Prefrerences > Advanced Settings > Web Content > Customize Fonts will let you adjust the text size to as high as 72px.
5. Does my text have enough contrast?
Just as small text becomes harder to read as we age, so does text with low contrast. So, even though that pink font on a white background might look perfectly readable to your eyes, you should still check for a contrast ratio of 5:1 (or 3:1 for large text, like headers).
How to check: You can get a contrast ratio by entering hex codes in this website.
6. Do the dynamic portions of my page include ARIA tags?
Adding ARIA tags in HTML is good practice, but it becomes particularly important for the dynamic elements of our websites. For example, hiding an element in CSS with
display: none controls only the visual display of that element. The element is still there in the DOM to be read aloud by a screen reader. That’s where ARIA comes in handy:
aria-hidden will hide that element from screen readers as well.