Today I’m creating a strategy for how to hold myself accountable for making this site accessible.
Disclaimer: I’ve been building websites for over 20 years, 13 of those have been spent focusing on accessibility through standards and progressive enhancements, using HTML elements correctly. Your mileage may vary.
Right, it all starts with this question:
“How many people will find it difficult to perceive and interact with my website?”
The question itself is important. I could have asked, “Is my website meeting WCAG 2.1 AA?” but I’m not.
By emphasising people over checklists, the focus always stays on the people and the impact I cause when I exclude them.
I’ll still use WCAG 2.1 AA as the bare minimum benchmark and with that question leading the way, I’m now going to do a systemic analysis of the state of accessibility for the past site.
This will serve as a learning exercise to see where I’m more ignorant—despite putting in time and effort towards making the previous site accessible, I’m certain there are things I’ve missed.
Unlike for performance, where I looked at the top-visited pages, I’ll be looking at every page for this.
I’ll use Google Lighthouse and Pa11y to run automated tests on my old website.
Lighthouse’s accessibility testing suite is pretty fucking basic and currently doesn’t include metrics to measure how long it takes before Assistive Technology can perceive and interact with pages but it’s better than nothing.
Though they might be improving this.
A score of 100% for accessibility doesn’t mean that the site is 100% accessible, it means that automated testing found no errors. Automated tests can only catch ~30% of issues.
And don’t get me started on overlay-peddlers.
When a measure becomes a target, it ceases to be a good measure. Goodhart’s law
But it’s a good way to start and find the most basic issues.
Meanwhile, Pa11y together with Pa11y CI, lets me iterate over a list of web pages and highlights detailed accessibility issues with their WCAG Success Criteria.
There are few different tools for testing the accessibility and whilst Pa11y—which uses HTML_CodeSniffer—doesn’t actually have the best coverage—that honour belongs to PowerMapper’s SortSite–it’s a good continuation.
You can see how these tools fared against each other in the tests that the Government Digital Service (GDS) Accessibility team did and what they found when they tested tools on the world’s least-accessible webpage.
After these, I’ll conduct manual tests using a checklist from The A11Y Project.
I would also like to hire a professional accessibility service to check my site but I don’t know if I can justify the cost for a personal site—to be continued.
After checking 367 pages on the old site. 295 of them passed without issues. On the remaining 72 pages, I found 143 issues.
I’ve published the raw accessibility data in a separate entry.
So, let’s see what those issues are.
Missing titles (92 occurrences)
Iframe element requires a non-empty title attribute that identifies the frame. H64: Using the title attribute of the frame and iframe elements
Where it’s happening: in Behind the Scenes of a Skillshare Class and other pages.
What it means: Write a damn title for all iframes. Make it meaningful and describe the content.
Additional info: All of my iframes are coming from Youtube embeds so I’ve filed an issue report to Youtube themselves because they ought to be including titles by default. I’m also going to update all the embeds to use the privacy-enhanced mode by using their cookie-less domain.
Low contrast (29 occurrences)
Issue isn’t present in current Reboot-state. Pending.
This element has insufficient contrast at this conformance level. G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text
Where it’s happening: in The First and Last Christmas and other pages.
What it means: I use specific colours on some entries. Not all those colours have enough contrast when used as the page title. Make sure your colours have enough damn contrast.
Additional info: This issue isn’t happening on the Reboot because I haven’t implemented this feature. Yet. If I do, I’ll need to make a note to review the colours.
Missing image alt texts (17 occurrences)
Img element missing an alt attribute. Use the alt attribute to specify a short text alternative. H37: Using alt attributes on img elements
Where it’s happening: in Zodiacs and Their True Meaning and other pages.
What it means: Write your damn text descriptions for images, or if they’re decorational, give them
Additional info: I’ve been writing text descriptions for images for years now but completely forgot to give these images
alt="" and a presentational role to signal that they are decorative.
Missing text alternative (2 occurrences)
Object elements must contain a text alternative after all other alternatives are exhausted. H53: Using the body of the object element
Where it’s happening: in A Christmas in Pictures and Another Christmas in Pictures.
What it means: I would need to provide a paragraph of text explaining the purpose of this slideshow of images, if the slideshow actually worked. But it’s coming from a Flash-powered Flickr embed that’s been deprecated for years. Remove your damn Flash embeds.
So, since Adobe is ending their support for Flash Player on December 31, 2020, I will end mine as well.
Additional info: This is now a bigger task because I’ll need to move the images from Flickr to the entries themselves. Realistically, this means I’ll do this in conjunction with the Reclaimer II project—that I haven’t talked about yet.
Duplicate ID value (1 occurrence)
Duplicate id attribute value found on the web page. F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID
Where it’s happening: in Topics.
What it means: The massive list of alphabetical Topics had the letter V appearing twice (because a Topic with special characters, À Rebours, was breaking it).
Additional info: The massive list has already been removed. I’ve deprecated the À Rebours topic—it was only used once anyway. This page still needs work but the issue has been addressed.
Anchor link without a destination (1 occurrence)
This link points to a named anchor within the document, but no anchor exists with that name. G124: Adding links at the top of the page to each area of the content
Where it’s happening: in A Scary, Hairy Beard Story.
What it means: The ‘Start’ anchor link is pointing to an anchor named
#week-0 but should point to the anchor named
Additional info: none.
Obsolete markup (1 occurrence)
Presentational markup used that has become obsolete in HTML5. H49: Using semantic markup to mark emphasized or special text
Where it’s happening: in The Frustrations of Web Design
What it means: I’m using the
<strike> element to represent deleted content.
Additional info: I think there’s a beautiful irony that one of the few entries I’ve written about web design, failing to do web design properly at that, is also an entry where I use a—what would have been even back then—deprecated element, thus, I’m also failing to do web design properly. Metalicious.
<strike> element was deprecated in HTML 4 and XHTML 1, and obsoleted in HTML5.
Shame on you Past Carlos.
Action points to address issues
Add titles to 92 iframes
File an issue report to Youtube
Update to privacy-enhanced mode by using cookie-less domain for Youtube embeds
- Review text contrast on 29 entries with custom colours
role="presentation"to decorative images
Migrate images from two Flickr albums to self-hosted alternative
Remove duplicate ID
Update anchor link to point to
- Manually found: Add captions to tables
- Manually found: Provide a skip link and make sure that it is visible when focused.
- Manually found: Use landmark elements to indicate important content regions.
Right, so going back to my question, of people I’m excluding, what’s the answer?
Depending on what entry you’re reading, I’m either excluding literally everyone because no one can perceive a deprecated Flash-player. Or I’m excluding some people because, whilst deprecated, the
<strike> element is supported in every latest version of every browser, but support in screen readers, such JAWS, is questionable.
The support for
<del> is questionable as well though but I should still use standard, supported elements.
In a less, “it depends,” manner, I can safely say I’m excluding at least 36 million Blind people who rely on Assistive Technology, such as screen readers to browse the web, so these issues will need to be addressed.
Moving forward I’ll also need to test all the new sections, so I’m not introducing new inaccessible shit.