Coding Journal

About Me

Explore

Accessibility Guidelines

Mark Lussenburg

⁠

For w3’s official accessibility guidelines; click me!⁠

⁠

Accessibility for Web Development

Intro

Accessibility for web development is making web content available for people with all types of disabilities, either permanent, temporary or situational disabilities.

Permanent disabilities can be issues like having only one arm, being blind or deaf.

Temporary disabilities can be situations like having a broken arm, Having cataract, which can cause temporary vision impairments, or having an ear infection.

Situational disabilities can be situations to you or your environment like having one arm less because you’re a parent with a newborn, being distracted by something visually, or being in a loud noisy crowd.

Benefits of having an accessible design can be the following:

Your solution will have better overall usability.

You’ll reach a larger audience (Approx 15% of the world have a sort of disability).

SEO ranks you higher if your site is accessible.

A fun list of companies who have been sued due to their websites or apps did not meet the American WCAG (Web Content Accessibility Guidelines) standards and lost:

⁠

BEYONCÉ - 9m $ lawsuit⁠

⁠

Domino’s - lawsuit still ongoing in 2021⁠

⁠

Burger King - 30000$ settlement lawsuit⁠

⁠

Netflix & Hulu - 800.000$ lawsuit⁠

⁠

Nike - Has an injunction to make the site accessible for screen readers.⁠

⁠

Amazon

⁠

Target - 9m $ lawsuit⁠

⁠

Rolex

Harvard University

Fox News

Which is yet another reason to prioritize developing accessible solutions.

The standard principles for WCAG are, your app must be Perceivable, Operable, Understandable and Robust.

Here is

a good visual resource for checking up on the guidelines of accessible design.⁠

⁠

Here is a resource to

check whether your color design is compliant to accessible design,⁠

⁠

and

a more thorough site checker that checks a whole web-application⁠

⁠

In addition, the Axe extension and Google Lighthouse for Chrome, can test CSS content and background colors for sufficient contrast as a part of an overall accessibility audit.

Perceivable

Making your app perceivable is what makes users able to perceive what’s going on on your application. Applying this accessibility to your application can be done in many ways.

Alternate descriptions

Images need to be not only specific, but also descriptive. I.E. the Alt-text for the image below would be okay with an alt-text like <img src=”pancakes.png” alt=”pancakes”>, but even better with an alt text like this: <img src=”pancakes.png” alt=”stack of blueberry pancakes with powdered sugar”>

⁠

However, what is not recommended for alt-text is leaving it empty OR stuffing it with SEO keywords.

Captions

Captions for video / sound material can help the hearing impaired users follow along. It is equally as important to match color contrast to the standards of accessibility as even having the captions in the first place.

Present content using semantic HTML

⁠

Two great readings for this issue can be found Here. (Mozilla)⁠

and Here. (Shayehowe)⁠

Adaptable design

It’s a good thing to include adaptability to your design, making sure each view looks equally good in all orientations. (such as Portrait / Landscape)

Visual cues

Making sure your visual cues appeal to everyone, including the colorblind. This can be done in a variety of ways. If you take the following image as a stand-point:

⁠

Then you can see how a person with red-green color-blindness is affected by a color-only validation system. To prevent this ambiguity, a way to display validation, can also be granted with either a check mark icon popping up when validation goes through, and an x icon when it fails. That is just one of many ways validation can be queued visually.

Avoid auto-starting video or audio

The simple explanation to why, is auto-started audio interferes with screen readers. Any sounds 3 seconds or longer, should come with the option to pause the sound, or lower the volume of the audio.

Responsive body copy

Keeping text for a maximum of 80 characters per line, and having sufficient line-height. The definition of sufficient line height according to the WCAG is minimum 1.5 line height between lines, and 2.25 between Paragraphs.

Text should also be legible at 200% zoom, users should not have to use horizontal scrolling to read a piece of content.

Operable

Keyboard Navigation

⁠

All accessible elements on a page must be accessible using the tab key. All users must also be able to exit an interface in an app. Inescapable key-board interfaces are known as keyboard traps.

Making sure that everything a user navigates is obviously in focus, is also a part of the WCAG. Browsing an application with weak focus indicators is practically the same as navigating a cursor with no opacity, you just don’t know what you’re clicking.

Allow enough time

If the essential functions of your website are time-based, then and only then, are you allowed to only allow your users to use the remaining time of your function. e.g. if you’re hosting an auctioning application where people can buy things within a time-limit. Otherwise if you have forms that have time-limits, then you are required to give users that need more time, the time they need to fill / use the forms or functions.

Disable distracting content

Content like video-animations, gifs, ads with sound should be an option a user of your system can turn on or off, because it can impair concentration and intent

Flashing animations

Be careful using flashing animations as content, we’ve all read the photo sensitivity and epilepsy warnings when using entertainment consoles, but in case that you haven’t

here’s a quick reading of why you should consider flashing animations in your design.⁠

Helpful navigation

Breadcrumbs, sub-categorization, proper semantic markup. This area is not too well documented as of June 2021, but more might be available once the Mozilla documentation Network gets a proper guideline set up on how to build keyboard-only navigators.

General helpful information

Help users understand where they are with a proper title tag.

Make clickable links descriptive, when screen reader users tabs to navigate, they only get the link text read out loud.

Keep a nice structured heading hierarchy

Use form labels meaningfully

Provide alternatives to complex interactions

Provide generous target sizes to buttons. Apples design guide suggests a minimum of 44 x 44 px (44 pixel points)

Understandable

Readable

Screen-readers must be able to know what language to use, and/or which accents to use.

Setting the language of a page can be done in the html tag.

or if a specific piece of text is in a different language, then it can be set for the specific piece of text

Plain Language

To clarify what plain language means, there are

guidelines that specify plain language guidelines for web applications.⁠

⁠

But to list some out, the recommendations are the following

Use strong, simple words.

Short paragraphs

Clearly organized information

Have a conversational tone

A good example of plain language from

plainlanguage.gov⁠

⁠

Create predictable navigation

To let users have a feeling of knowing what to expect while browsing your website. This also means keeping the way of navigating your site consistent.

No unexpected changes in context

People only expect major changes when initiating certain actions, like these:

Interacting with an interface element

Opening a new window

Loading a new page

Significantly rearranging page content

Moving focus to a new component.

The Mozilla developer network says on the subject. “People don’t want interfaces to surprise them. They want things to be intuitive and behave as expected”

Input assistance

Like in the Perceivable section under Visual cues,

Here are a few guidelines to help users understand how they’re using forms incorrectly⁠

⁠

They include information on

Making messages easy to notice and understand

Highlighting errors visually

Keeping instructions simple

And even more.

Robust

The final element of the WCAG “Robust”, states that content must be robust enough that it can be interpreted by a wide variety of users, including users using assistive technologies.

What does that mean in practice?

It means that we must make sure our HTML is valid while using correct semantic markup.

Use validators to make sure your errors get caught before being released, everyone can make mistakes!

⁠

Check out this HTML5 validator!⁠

⁠

It can even check for misused semantic elements.

The Robust principle also demands use of status messages to elements that adds content to a website, like Javascript that might add list elements to a site without refreshing the page.

⁠

This is how a screen-reader reacts to dynamically added content⁠

⁠

To help developers debug accessibility,

Here is a link to the Axe accessibility debugger extension⁠

⁠

Working accessibility into practice

The first tool that’s readily available is

The accessibility checklist for web developers⁠

⁠

The benefit of the checklist above, is that it visualizes the important elements of the WCAG guidelines. The PDF is even interact-able, meaning you can copy it and use it for multiple projects, or even print out copies to share with the working team.

An important note is however, just because you follow every guideline on the checklist, does not mean you will automatically end up with an accessible solution. It is a good idea to always have accessibility in mind when developing, and equally important to have everyone you work with on a given project, to keep it in mind as well.

It should be natural to start considering accessibility, even as early as in the research / design phases of a project.

Involving disabled users in user testing is equally critical. As for today, the rewards of developing accessible solutions, outweigh the costs by a large margin.

⁠

A reading about including disabled users to user testing / Quality assurance⁠

⁠

Tips for conducting usability studies with participants with disabilities⁠

⁠

And finally a fully fledged accessibility guide developed by apple⁠

Form usability

According to the

Baymard institute of user experience⁠

, over 40% of users abandon shopping carts in checkout due to difficulties with form usability, and users not being able to pass form validation. In turn, the user then abandons the cart and searches elsewhere for the product they’re looking for.

The principles of an accessible form are listed below.

Avoid unnecessary questions

Minimize questions per screen

Provide context clues

Group related questions

Use clear input labels

Make focus indicators obvious

Help users spot and correct errors (Refer to Understandable, Input assistance in the doc.)

To avoid making forms difficult to deal with for everyone, generally avoid making forms too long. A term in web development that allows people of all cognitive levels to fill in a form is called Chunking. When chunking a form, you break it down into several smaller sections where each section is a step of the form.

It’s important that when chunking a form you need to make sure all of below is true:

You are reminding the user of the purpose of the form

The form contains a clear label of the current step

The user knows how much of the form that has been filled in

The user knows how much of the form is remaining

When all of above is true, users with cognitive disabilities or memory impairments, can still relatively easily complete a form.

When it comes to helping the user write what’s in the form. Placeholder text is generally a bad idea, either if the text in the placeholder is too light, visually impaired might not be able to read what the placeholder text says. If it’s too dark, it can be confused with preloaded data in the field. A better solution to placeholder text is input masks.

Here is an article from Baynard about input masks⁠

It’s better to format the users data when they’re done writing it, than trying to nudge them in the right direction before they start writing.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.