Creating Accessible Content

The Historians' History of the World - Title Page — There's nothing wrong with leaning into your title content

Page Titles

Page titles should be unique and descriptive. The content in the title element of your page's head should give users a concise, but solid description of how this page differs from any other page, and what the content is going to be.

If this is the second page in a series of three pages, say so!

Reference: WCAG, Page Titled - Understanding Success Criterion 2.4.2 Opens in a new window

Headings

Headings should structure your document. Think of the way your information is structured - it's rarely appropriate to just have a single heading and then paragraphs all the way down. Headings should provide meaning and context.

To the devs out there: all the worst abuses I've seen of semantics have been heading elements. If your design team and your content team aren't rigorously aligned (and when are they ever?), you need to abstract your heading styles from your heading elements.

Reference: WCAG, Section Headings - Understanding Success Criterion 2.4.10 Opens in a new window

Alt Text

A woman blowing dandelion fluff, for reasons totally unrelated to the content of this page — Are stock photos content? Should screen reader users be spared the grinding dullness of the blogosphere?

Alternative text should be your best effort to convey all of the relevant information in the image - no more, no less. To that end, images that are purely used as decorative elements, i.e. textures and backgrounds, require an empty alt tag to indicate that there is no information conveyed (as opposed to omitting the alt texts, which only conveys that you forgot to add alt text).

Alternative text for spatial information

This gets tricky when you get into things like graphs. In graphs and charts, specific data is conveyed visually down to a granular level. Creating a data-point-perfect text alternative to a line graph is a tremendous challenge.

When deciding on an appropriate text alternative for visually represented data, consider first whether you're presenting this information with the expectation that users can do their own analysis. If not, consider communicating in plain language what it is that you want your users to take away from your content. Has your stock value steadily risen since 1987? Then say so, rather than trying to impress a few people, while creating a barrier for others.

When you really are trying to provide people with data, the WCAG suggests that a data table may be sufficient. However, this is hardly a true alternative. The team behind Highcharts.js Opens in a new window have been working towards displaying data in a way that is truly navigable for users accessing the data without a mouse or with a screenreader. Unfortunately, D3.js Opens in a new window isn't showing signs of making their leading library of SVG-driven data visualization accessible.

Reference: Non-text content - Understanding Success Criterion 1.1.1 Opens in a new window

Transcripts and Captions

Audio and video need transcriptions and/or captions. The simplest way to do this - submit a video to Youtube, wait for the automated transcription to generate (be patient, it can take a few hours), and then correct any errors.

Remember to keep an ear out for sounds that convey relevant information, and make sure they're included - not just the words.

Reference: WCAG, Non-text content - Understanding Success Criterion 1.1.1 Opens in a new window

Form Labels, Instructions and Errors

Be clear about what's expected of a user, and how errors should be resolved. This is a fundamental usability heuristic Opens in a new window - it doesn't just apply to accessibility. A red asterisk appearing suddenly adjacent to an input isn't helpful to everyone. Be explicit.

Reference: WCAG, Input Assistance - Understanding Guideline 3.3 Opens in a new window

Beware Things That Look Like Text

A text-based tattoo of a to-do list — This text is not accessible

Be on the lookout for images with embedded text, or worse - OCR-resistant PDFs.

Images with embedded text need to have diligent alternative text provided.

PDFs can be made to be accessible Opens in a new window, but scanned pages of a book won't cut it on their own!

ASCII

I have yet to test a screen reader that speaks the following set of characters in the same way: ¯_(ツ)_/¯. Absolutely none of them recognize it is as "the shrug emoji".

For the same reason, write the phrase as "16 to 17 years old", instead of "16-17 years old".

Links - do's and don'ts

Don't confuse Link with Zelda

Don't make the text of a link a URL. Most screen readers make link text 'unskippable', and hearing a URL read out character by character is just awful.
Do keep your link text short. See above.
Don't make link text ALL CAPS. Many screen readers will assume they're acronyms and read them out letter-by-excruciating-letter.
Don't tell screen reader users that a link is a link - the screen reader will tell them for you.
Do use the link text to distinguish the link. 'Click here' is a fail. 'Download' is a fail. Links need to say what they're about, not give generic calls to action.
Do describe the behaviour of a link. Is it a download? Does it open in a new tab? Throw some screen-reader-only text in there if (if) you don't want to tell everyone what your link is going to do.
Don't describe the link behaviour with an icon in a pseudo-element. Pseudo-elements (i.e. :before and :after) are not a part of the DOM and do not get read by screen readers.
Don't make links out of things that aren't links. Why do to the trouble of making a span act like an anchor when you can just use an anchor and have all the native functionality come with it?
Don't let your links get broken. It's bad for SEO, it's bad for usability, and it just comes across as tacky.
Do describe the behaviour of a link that contains an image in the image's alt attribute (in addition to the image's text alternative).