11 Web Solutions That Ruin(ed) Accessibility

In 2022, accessibility has developed into an increasingly important topic. With the introduction of multiple new accessibility regulations, the internet is bound to become more friendly to users with impairments. And this blog series’ goal is to help you join the family of accessible web solutions.

If you have read our previous entry about accessibility, you now know what to do to add simple accessibility elements that will have to potential to make a visible impact (pun intended).

This time, I’ll take you on a journey through some major accessibility culprits from the web – old and new. Some are long gone, and others still haunt accessibility-needing internet users. Many of them changed the web forever – but all of them were (are) a horror for people with impairments.

Let’s jump right it. The first position on the list takes us to the colourful 80s.

Because unfortunately, a year ago, 98% of web pages still weren’t accessible.

Animated GIF Banners

GIFs were one of the pioneers in file transparency support. They enabled to add animations easily – as tiny files. However, this great trait quickly turned out to be a problem.

Web creators started to overuse GIF files to make up for blank spaces on their websites. And the result was usually neither accessible nor responsive.

Being so easy to use, GIFs quickly became a popular ad format. They were everywhere; I’m sure you stumbled upon hundreds of them (daily) a few years back. Yet, since GIFs only supported 256 colours in one file, they looked hideous on high-resolution screens (which were a market standard even back then).

This issue didn’t stop advertisers and web creators from overpacking their platforms with all sorts of GIF banners. Today, these GIFs would violate at least a few WCAG guidelines.

However, GIFs can actually be an accessible website element – but they have to follow a few WCAG rules:

1.1.1 Non-text Content
1.4.1 Use of Color
1.4.3 Contrast (Minimum)
1.4.5 Images of Text
2.2.1 Timing Adjustable
2.2.2 Pause, Stop, Hide

But since these guidelines transform GIF animations into static pictures, today, this format isn’t popular anymore. (Or rather, it is – but only as memes).

Macromedia (Adobe) Flash

Flash, created in 1996, was designed to enable creating scalable, interactive pictures and animations. It was widely popular; some used it to write entire web apps. Even YouTube used it – to watch videos on the platform, you needed Flash.

However, last January, after 24 years, the all-present Flash was finally gone. Surprising to non-technical people, the technology had some major flaws.

First, Flash was everything but accessible. After some time, Adobe finally started adding accessibility support, but it was too late. The industry, accustomed to designing solutions the same as before, didn’t embrace the accessibility options.
Next, Flash wasn’t very compatible. For example, Firefox experienced recurring crashes on Flash-containing websites – even if the latter were only minor elements.
Finally, the technology also experienced several security issues. The plug had to be patched practically every month.

SVG and Font Awesome

Flash’s two main successors – Scalable Vector Graphics and Font Awesome – are great when it comes to scalable graphics and icons. However, they come with a tricky accessibility challenge.

If not part of style but inserted directly into HTML code, they become not accessible. In both cases, ARIA attributes are necessary to generate alt content. And developers usually forget about that part! Luckily, there are two useful documents that can help: Font Awesome Accessibility and Accessible SVG.

Captcha

Arguably the biggest accessibility issue online, Captcha pictures are not only great at keeping away bots – but also people with impairments.

This functionality emerged in 1997 to verify if the individual filling out a web formula is a person or just AI (so-called Turing test). At the same time, they also became an unbeatable challenge for certain users – for example, people with vision loss.

Screen readers are no help – they can’t identify text on pictures. To solve this issue, a voice captcha joined the scene. Unfortunately, it only works with English – making it unusable for many, many people.

Currently, reCAPTCHA 3 delivers hope for the future – because, at this point, no Captcha solution is fully accessible.

Email Software

Creating and sending out picture-rich messages became popular as soon as email software started interpreting HTML documents. Currently, accessibility standards dictate that mailing should be clear and accessible. However, email software – like, for example, Microsoft Outlook – do not excel at making this easy.

Did you ever try creating an email template that will not only be responsive but also follow WCAG guidelines? If not – good luck! Not only will you be forced to use the old HTML 4.01 – the email will also have to be created as a… table (which goes against WCAG guidelines). And that’s only the tip of the iceberg.

Even the latest Office 365 or 2021 pack isn’t able to display an accessible email based on HTML5.

Placeholders

My personal anti-accessibility champions. Placeholders exist since the dawn of time (or rather, the internet), and since they’re easy to design and implement, they’re frequently (over)used.

What makes them so inaccessible?

First, placeholders shouldn’t be an alternative to a description – otherwise they will be seen by screen readers as content (even if nothing was inserted yet).
A placeholder disappears right after the user starts writing – thus, they lose the instruction.
The default style doesn’t offer the minimal contrast for text under 18px.
The placeholder font is small, which makes it hard to read. A placeholder isn’t translated automatically by translation software.
Finally, top design services like Smashing Magazine or Nilsen Normal Group say – don’t use placeholders.

Parallax

The first parallax effect was created in 2007; however, the technology didn’t become popular until the era of HTML5 and CSS3.

Animated backgrounds on web pages enabled to add some unique character to web pages. Even today, parallaxes remain visually appealing – but not without an impact on accessibility.

Most importantly, parallaxes can affect people suffering from vestibular neuritis. Specifically, they’re able to cause prolonged vertigo. That’s why it’s not recommended to add parallaxes to websites. The WCAG requirement 2.3.3: Animation from Interactions even states this directly.

ARIA

ARIA is mainly helpful where code semantics is lacking. It enables supporting technologies understand what a given element on a website is for.

ARIA itself is not an accessibility problem. In theory, it’s a solution limiting accessibility issues or adding accessibility elements where HTML can’t. But…

Somebody once said that if ARIA wouldn’t exist, many accessibility problems also wouldn’t. Unfortunately, an incorrect use of ARIA is even worse than a lack of ARIA.

Thus, if you’re not skilled with ARIA, don’t use it. Instead – read this WAI tutorial on using ARIA.

CMS – Content Management Systems

Content Management Systems are not a good environment for accessibility. There are plenty of causes – like costs, ease of use, and working speed. Often, content management systems are published in very basic forms and have more features added later on.

Unfortunately, this doesn’t include accessibility standards. Accessibility isn’t a plugin that can be added later on. Practically, if a CMS isn’t built with accessibility in mind from the ground up – before inserting any data – it will, most likely, never become accessible. It would take incredible effort to get it done, which often goes against business priorities.

In 2021, none of the CMS systems I have seen was compliant with WCAG 2.1. I hope the future will bring a significant change.

Clickable Divs

In the era of programming frameworks, static code analyses, validators, and other tools, accessibility issues in that regards should be nearly non-existent. But, as you’ve probably guessed, there are everything but that.

For example, you can still stumble upon html code like a div tag with onClick() that’s not a link, but only a simulation of such a link or button. In this example, div or span are not a focusable element, so they will never be accessible.

Of course, with ARIA and other HTML5 attributes, you can try really hard and make these elements accessible. But why bother, when you can get this done by the book?

In this case, the div itself is not the problem. The issue lies in the way of thinking – taking shortcuts.

Conclusion

Were you surprised by some of the examples from this list? Some of them are quite popular. Does this mean you should use them?

Not necessarily.

The crucial first step requires a bigger awareness. If you understand some of the accessibility issues in the major tools or solutions, you can at least try to limit their effect. And with a little luck, you’ll make the digital space at least a little bit friendlier for people that require accessibility.