8 Weird Tips Accessibility Specialists Don’t Want You to Know!

Number 4 Will Give You a Seizure

The title is written as a so-called clickbait title and meant as a tongue-in-cheek joke. Often clickbait titles deceptively present tips as a form of powerful secret knowledge. In this case, accessibility specialists don’t want you to know these tips because they’re bad practice. These are tips you shouldn’t follow.

1. Using abbreviations improves your readability score

“A good F-K score is important for A11Y because of the U in WCAG’s POUR.“

Creating understandable content is a core principle of the Web Content Accessibility Guidelines (WCAG). Readability is a big part of creating understandable content. I often struggle with writing simple language myself. I tend to use long words and sentences that seem never-ending. To make things easier, I and many others use a readability tool. I am currently typing this in Hemingway: a simple writing app that shows a readability score. This score is based on a Flesch–Kincaid readability test. It takes the total number of sentences, words and syllables and calculates a score from it.

Keeping an eye on my score helps me focus on the goal of my text: to clearly communicate a message. There are some pitfalls though. Words with few syllables score better than words with many syllables. Abbreviations are often counted as words with few syllables. As we can learn from WCAG, abbreviations can confuse readers. So even though abbreviations give a higher score they should often be avoided. The same goes for another bias of readability scores. You get a better score by using short sentences. But when you start to omit words to shorten sentences, the end result might be less readable.

A Flesch-Kincaid score is a great metric to keep you focused on readability, but it’s not the final goal of your text.

2. Pages that use WAI-ARIA are less accessible

In February 2019, WebAIM automatically tested 1.000.000 web pages for accessibility issues. Such a huge dataset gives great insight in the current state of the web. Many interesting conclusions were drawn from the results. One of them was: “Home pages with ARIA present averaged 26.7 more detectable errors than pages without ARIA”. That’s a pretty demotivating statistic.

I think it’s pretty understandable though. Adding ARIA is an advanced technique. One of the main uses for ARIA is enabling developers to create their own accessible widgets and elements that are not available as native HTML elements. This means that whenever you find ARIA on a page, it is likely being used to create a technically complex component. With complex components, the chance of issues significantly increases.

So should you not use ARIA? Well if you don’t need it, don’t use it. But in some cases, you may have no other option. There is no <tablist> or <tabpanel> in HTML. However, the ARIA Authoring Practices showcase ways to build such Tab widgets.

The real tip is not to avoid ARIA in itself, but to avoid using ARIA in situations where it isn’t necessary.

3. Automated tests cover only 20% of WCAG

Many numbers are thrown around in conversations and presentations about automated accessibility. And whether you believe they cover 10% to 30% of possible issues, or 20% of the WCAG criteria, it doesn’t really matter.

Any issue found by an automated test takes 0 effort. That’s the important number. These are issues with no investigation cost, available at any point of a development cycle. Besides that, that 20% of WCAG might be the cause of 60% of your issues. Automated testing finds the low hanging fruit. My experience is, low hanging fruit is the most plentiful type of fruit.

Add a manual keyboard test to your automatic test and you probably catch the vast majority of issues. A manual keyboard test consists of the following:

1. Go through your page with the Tab-key.
2. Make sure every interactive element can be reached.
3. Make sure every interactive element can used.
4. Make sure the order is logical.
5. Make sure the focus is visible.
6. Do the same in reverse with Shift + Tab.

Congratulations, you can now find a ton of issues with hardly any effort.

4. You can offer an accessible alternative

WCAG has a sort of escape mechanism for those who like loopholes. Whenever you have a page that doesn’t conform, you can offer a ‘conforming alternate version’. It needs to offer the same information and functionality. It should be reachable in a way that has no barriers. A constantly flashing page that includes a link to a conforming alternate version is not a solution. Flashing pages can cause seizures. A visitor that experiences seizures from flashes will quite likely suffer these before even reaching the alternative version.

If you’re clearly able to build a conforming page, why would you go through the effort of creating an alternate version anyway? It’s easily twice the work, which nobody likes. But it’s also a loss for your users. It hides all accessibility improvements from people who might not identify as being disabled. They could benefit from the improvements though. A solved accessibility issue often means improved usability for everyone. By giving everybody the same inclusively designed experience, you will give people with disabilities the confirmation that they belong. They are not some alternate version hidden behind a link.

5. Write extensive aria-labels for blind people.

Unfortunately, I have come across labels supposedly written specifically for visually impaired people. One example was what should have been simple navigation on a website. It was visually clearly labelled and straightforward to use. It contained links with concise names that matched their destination like ‘home’ and ‘settings’. Using a screen reader, however, was a whole different experience. The menu had a label that sounded like: “This main menu is where you can navigate the website”. The link to settings was labeled with: “The settings page allows you to change things like your account name or contact information”.

While well intended, it is not helping anyone. Being blind does not mean you don’t know what a menu is for, or what a settings page might offer you. Treating people like they’re helpless, will make them feel helpless. It’s like the mansplaining of accessibility. Ablesplaining?

When writing accessible names write short functional aria-labels that people can quickly understand. Usage instructions aren’t necessary.

6. Only a small number of our customers have disabilities

This is a fallacy that never ceases to amaze me. More than 15% of the world population has a disability. I tried counting them once, it was not a small number. When more than 1 billion people might have trouble accessing digital information and services, we don’t call that a small number.

Maybe you do have a website that has few visitors with disabilities. Have you considered that’s actually a good reason to make it accessible? Increase your reach. Stand out. The business cases for accessibility are plenty.

The discussion however, should never be about the number of people. Talking about numbers gives the impression that, somewhere down the line, there is a reasonable amount of people you’re willing to discriminate against and exclude. Whenever somebody asks you about numbers, tell them it’s the wrong question to ask. Even when the numbers are small, the numbers don’t matter.

7. The default focus indicator is safe

Safe is a dangerous word here, but technically, a default focus indicator is allowed by WCAG. If all you’re worried about is conforming to WCAG, you’re done here. (Although some people interpret this success criterion of WCAG in such a way that changing background color can invalidate the default focus indicator.)

Odds are that the default focus indicator is very hard to see on parts of your website. You are likely able to do much better than the default. When your only aim is to pass WCAG, you’re doing the accessibility equivalent of “Teaching to the test”. You might score well the short term, but when you see it’s only a tool and not a goal, much larger long term gains can be achieved.

On the upside, default focus indicators are getting better.

8. Distinguish elements on your page by using a catchy font

WCAG Success Criterion 1.4.1 tells us we can’t use color alone to communicate something. An example of a failure could be marking your errors in a form with red. Or the color of the current page within a navigation differs from the other links. Another familiar example is having blue links on your page but without the characteristic underlines.

By relying on color alone, you’re excluding people with limited (color) vision.

There are many ways to solve this as the criterion is pretty forgiving. Just don’t use color as your sole visual means of communication. You could add a proper error message to your red markings. You could change the font-weight of the current page. You can make sure your links have underlines.

Or… you could change the font of your links. Technically, you’d be completely conforming. You could even change the font to Wingdings, the famous Windows font that consists entirely of icons. Completely unreadable, but valid for the 1.4.1 Criterion. Slightly changing kerning, line height, font size… any minimal change that is not based on color is sufficient.

WCAG has four principles and 1.4.1 falls under the first of four: Perceivable. What you communicate should be perceivable by everybody. Minimal changes show minimal effort and do not follow the intent of this principle. You want your communication to be clearly perceivable.

Creative solutions are often less effective than conventions. Changing a font can be useless for a user that has a custom font to override yours.

Wrapping up…

Whenever you see a tip, judge it by its merit for your users. If it doesn’t improve anything for their experience, be critical. The accessibility community is open and welcoming. Always feel free to ask the opinion of others.