Skip to content
Coding Journal

icon picker
Accessibility Guidelines

Accessibility for Web Development


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:
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.
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.


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 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

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.


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

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)



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.
<html lang=”en”>
or if a specific piece of text is in a different language, then it can be set for the specific piece of text
<p lang=”dk”>Som Jeg gør her :)</p>

Plain Language

To clarify what plain language means, there are
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 :

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

They include information on
Making messages easy to notice and understand
Highlighting errors visually
Keeping instructions simple
And even more.


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!
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.
To help developers debug accessibility,

Working accessibility into practice

The first tool that’s readily available is
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.

Form usability

According to the , 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.
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 (
) instead.