In acknowledgement of Global Accessibility Awareness Day (GAAD), I've finally done something I've been meaning to do since I started coding 10 years ago. I listened to my website with a screen reader.

Using my portfolio site, I recorded a bit of the Screen Reader Audio

At first it was overwhelming. All those extra words made it sound like gibberish. There are lots of settings, with differences between OS updates, and I still don't know how to get it to just slow down, pause or go back. A handicapped person would certainly need knowledgeable help to get a working system set up.

According to the CDC, 1 in 4 adults in the US have serious difficulty doing the things I take for granted. Difficulties that would make it hard to work a keyboard, see, hear and understanding web content. The pandemic would have only made things worse for many of these people.

Fortunately, according to Mozilla's Accessibility Learning Area, HTML used correctly is a strong starting point. There's also a fair amount of overlap with good SEO practices and Accessibility.

Besides compassion, there are other reasons to up one's game in this aspect of front-end development. For one, handicapped people buy stuff, too, so that's motivation for business owners. For another reason, it's the law. Enforcement comes about through someone sueing the web owner, so my advice is to not aggravate and confuse your site visitor!

Web Content Accessibility Guideline (WCAG)

The World Wide Web Consortium (W3C) develops standards for the web. It's official accessibility guidelines are spelled out in the WCAG, the Web Content Accessibility Guideline.

I tried, I really did try to read the WCAG documentation - even made a spreadsheet. Finally, I gave up. It's probably good to have such a comprehensive gathering of info somewhere... but in practical terms, everyday web devs who are struggling to keep up with the latest tech, so they can make a living, will be too discouraged to follow through with that set of docs. :}

Thank Goodness for The A11y Project!

The A11Y Project is a community-driven effort to make digital accessibility easier.

A11y is a symbol for the word 'Accessibility'. 'A' followed by 11 characters, then 'y'

They have a Checklist, written in language I can understand with linked references to the official Guidelines.

There are 15 main categories and several sub-categories that each deserve enough study to produce their own article. I can see why the industry of accessibility testing is going strong! It's a specialty.

Initially, I intended go through each one of the items and make sure I had them included in my website boilerplate and thought process. But that's going to take more time than I have right now.

So, this article is going to be more of a planning exercise. I'll look at each category and see what I'm already doing and what I still need to learn, with some references for study.

I know this will help me learn. I hope it will give you some tips and perspective, too.

The Checklist

Content

Simple, direct, easy to read content is important for everyone who comes to a website.

📋 Button, anchor and label content needs to stand alone with respect to its meaning. Good for SEO, too. It takes a little extra creative effort.

Global Content

Responsive code design and standards-compliant HTML takes care of a lot of these items.

📋 Semantic HTML provides good info for screen readers except for the generic div, section and form elements. I need to learn more about ARIA (Accessible Rich Internet Applications) attributes, especially now that I'm learning how to build web apps with JavaScript.

Keyboard

Tab through the website and see if the focus order makes sense.

📋 I hate the default outline style that browsers apply to active links. CSS-Tricks has a few modern articles on creating my own styles for those :focus elements.

Images

Make sure all images have the alt text attribute, even if they're purely decorative, then the alt should be null, as in no-space.

📋 I need to experiment with null alt attributes to see how they sound. I've been adding a space character all this time and the screen reader says, "unlabelled image" which sounds irresponsible to me. :\

📋 There are a lot of recommendations for best use of alt text. WordPress users, did you notice the link to An alt Decision Tree that core provided sometime in the last few years?

Headings

Headings are for grouping written content in meaningful ways (not for decoration). Well-organized use of h1, h2, h3, etc. tags are helpful to everyone, disabled or not. It's also good SEO.

There should only be one h1 on a page for accessibility. This means the site title needs to use a different element.

Lists

Use the right list elements for lists.

Controls

Lots of good, common sense guidance in this section. Use anchor elements for links, the button element for buttons.

📋 None of the links in this article automatically open to a new tab/window, but if they did one needs to notify the site visitor it's going to happen. I wish we had a universal ASCII symbol for links that open in a new tab. I'll need to test if/how screen readers pick up the target attribute.

📋 I recently started using 'skip-links' in my websites, but need to review them for updates. Again, a CSS-Tricks' article How to Create a “Skip to Content” Link looks like a good starting point.

Tables

Semantics, again. Use table elements for tabulated info. The Guidelines ask that th and caption elements be used as well. I haven't been using those regularly.

📋 I'm going to have to look up the scope attribute, which the Guidelines ask for.

Forms

Make sure forms are well-organized and labelled.

📋 Learn best practices for styling error and other status messages.

Media, including Video and Audio

Don't auto-play and make sure controls are available. The Guidelines on providing readable text applies; use captions and transcripts.

📋 This means I should have prepared a transcript of the audio I've included above. Have you ever typed up your own transcript? It takes a good amount of effort and time, and a helpful transcription app, that my clients would probably not pay for.

Appearance

Using a simple, straightforward layout is good for all users, and is forced upon us when thinking in 'mobile-first' mode.

I already test my websites in all the modern, popular browser and the mobile devices I have at my disposal. The WCAG Guidelines also asks us to test in specialized browsing modes, such as Windows High Contrast or Inverted Colors. For freelancers this will add costs to a project that clients may not want to pay.

📋 I'll need to learn the different specialized browsing modes on Window and Mac OS and test which styles are broken by those modes.

📋 I've never done it before, but increasing text to 200% would be a good test.

📋 Another design pattern I've never considered can be evaluated by what's called The Straw Test. It's always a good principle to not spread content over too wide an area.

Animation

Content that moves can be problematic to some people. Here are the items to check for.

• Ensure animations are subtle and do not flash too much.
• Provide a mechanism to pause background video.
• Make sure all animation obeys the 'prefers-reduced-motion' media query.

Color Contrast

📋 Normal and large-sized text, and icons all have specific contrast ratios. Here's a tool for calculating color contrast ratios. I didn't even know it could be calculated!

As always, make sure text over graphics are clear.

📋 There is a CSS pseudo-element I wasn't familiar with, although I've enjoyed its use on some websites. It's the ::selection pseudo-element and it adds style to text that the user has highlighted. As you can imagine, make sure the reader can still read the text.

Mobile and Touch

The sub-categories of this one are all the same as good, mobile-first, responsive styling. Make sure the site can be rotated, check the distance between links and buttons.

📋 I've been seeing horizontal scrolling lately. The Guidelines say not to do it, but it looks useful in some cases. More research is needed on this.

Okay, so that's the list I'm going to be working with. There's no such thing as 100% Accessible. We can only keep striving to improve.

Let me and anyone reading know of additional tips, references or experiences you have. Best!