This is a post for my #100DaysOfCode Day 2 based on freeCodeCamp material I learned.
Websites should be open and accessible to everyone, regardless of a user's abilities, but often the opposite happens. Here's a quick cheat sheet on improving a web site's accessibility using HTML and CSS.
1. Images should have alternative text when their contents are not obvious from reading the text
<img src="logo.jpeg" alt="Company logo">
2. h1 - h6 text are important for screen readers, keep their order
<!-- Don't do this -->
<h1>A header</h1>
<h4>A smaller header</h4>
<!-- Do this -->
<h1>A header</h1>
<h2>A smaller header</h2>
3. Give structure to your page by using main, header, footer, nav, article, section, and audio
<header>
<h1>The header!</h1>
</header>
<main>The document body</main>
<footer></footer>
4. Use article element for blog entries, forum posts, or news articles
<div> - groups content
<section> - groups related content
<article> - groups independent, self-contained content
5. Use both visual and auditory content
So users with visual and/or auditory impairments could access it.
6. Use the figure element for charts
<figure>
<img src="your_chart.jpeg" alt="Short description of the chart">
<br>
<figcaption>
Description of the chart.
</figcaption>
</figure>
7. Use label elements with inputs
<label for="name">Name:</label>
<input type="text" id="name" name="name">
8. Group radio buttons in fieldsets
<fieldset>
<legend>Choose one of these three items:</legend>
<input id="one" type="radio" name="items" value="one">
<label for="one">Choice One</label><br>
<input id="two" type="radio" name="items" value="two">
<label for="two">Choice Two</label><br>
<input id="three" type="radio" name="items" value="three">
<label for="three">Choice Three</label>
</fieldset>
9. Use date fields with a picker
<label for="input1">Enter a date:</label>
<input type="date" id="input1" name="input1">
10. Standartize time with time element
This element's datetime attribute is the value accessed by assistive devices. It helps avoid confusion by stating a standardized version of a time, even if it's written in an informal or colloquial manner in the text.
<time datetime="2013-02-13">last Wednesday</time>
11. Make some content visible only for screen readers
Like this:
.sr-only {
position: absolute;
left: -10000px;
width: 1px;
height: 1px;
top: auto;
overflow: hidden;
}
Don't use:
display: none; or visibility: hidden; they hide content for everyone, including screen reader users
zero values for pixel sizes, such as width: 0px; height: 0px; it removes that element from the flow of your document, screen readers will ignore it
12. Use high contrast text
The Web Content Accessibility Guidelines (WCAG) recommend at least a 4.5 to 1 contrast ratio for normal text. The ratio is calculated by comparing the relative luminance values of two colors. This ranges from 1:1 for the same color, or no contrast, to 21:1 for white against black. Foreground and background colors need sufficient contrast so colorblind users can distinguish them.
13. Use descriptive link text
This:
<a href="">information about computers</a>
is better than this:
<a href="">Click here</a>
14. Use access keys for important links
<button accesskey="b">Important Button</button>
15. Use tabindex to add keyboard focus
Links and form controls automatically get keyboard focus when a user tabs through a page. This functionality can be given to any other element by using a tabindex="n" on them, where n is not negative.
<a href="" tabindex="1">First accessed link</a>
<a href="" tabindex="2">Second accessed link</a>
Photo by Rodion Kutsaev on Unsplash
Top comments (21)
I'm really happy to see accessibility getting covered! It's a really important part of web development, and it's a foundational part of the web.
That being said, there's a couple of antipatterns in this article that need addressing:
The
.sr-onlyshould be updated to use properties that does not create mispronunciation when read by a screen reader.Interactive elements such as
a, andbuttondo not need atabindexapplied to them, as they can already receive keyboard focus. Additionally, usingtabindexvalues greater than0is discouraged, as it creates a tab order that differs from the natural document tab order. This can create a frustrating and disorienting experience for people who use assistive technology, as they may be prevented from navigating to an interactive element on the page, or be navigated to to one that they did not expect to follow next. The Paciello Group has written about this in more detail.I would also advise against using the
accesskeyattribute, as it is problematic for a variety of reasons.The other techniques presented are great things to be aware of, and I'm really enjoying having them all collected in one place like this.
+1 to Eric's comments, especially the mention of accessibility getting covered!
One other thing I'd love you to add to any
aelement: please be sure thosehrefattributes are not empty... that ensures that theawill be reachable by keyboard users.Thanks again for making a good list for beginners to accessibility.
Thank you for your comment Eric, I'm a beginner myself with this topic, I'll read the links carefully.
The golden rule of using [tabindex] is: never use values other than 0 and -1. Any other value changes the default focus order, creating unexpected experience for the user.
There is also issue with
[accesskey]as it's not usable across browsers. Nearly every browser has its own format for shortcuts. In most cases it's better to implement keyboard shortcuts with some scripting.Thank you for your comment Tomasz, I'll learn more about the topic.
Nice starter. A few things I'm missing are:
aria-labelfor descriptions that only screen readers should read out,aria-hiddento hide stuff from being read outbuttonfor any element that works as a button (even outside of a form) so the browser will translate keypresses of space or enter into click eventstabindex="0"will set the tabindex in the DOM element order after those elements with a tabindex higher than zeroThank you, Alex! I'll edit the post with this information.
I've never seen the accesskey attribute before, quite cool! How would you communicate to the user what accesskeys do what though?
aria-describedby on the body, linking to a (hidden until activated by non-visually-impaired user) list of keyboard shortcuts. Caveat: different browsers / OS will need different keys (see developer.mozilla.org/de/docs/Web/...), so either create the list with JS or prefix it with a short description.
You could also use [ALT]-[key] as a default and distinguish the browsers on Windows with different behavior ([ALT]-[SHIFT]-[key] on Firefox, [Shift]-[ESC] + [key] on Opera <= 12, or ignore this one as it is basically not used anymore nowadays) using CSS hacks and add a note about [CTRL]-[ALT]-[key] on Mac (and ignore Firefox prior to version 14, which used [CTRL]-[key] instead).
Wow that's really cool so it's like a key/legend that only visually impaired people will see
You can also let power-users "see" it when they activate it in a submenu. Accessibility is for everyone.
Yeah for web apps that would be ideal, no harm in displaying shortcuts for everyone. I'm sure Atlassian do this for a few of their tools.
One thing I do wonder though is how it would differ from just making sure your website is accessible via tabbing? or is it just a shortcut to stuff so you don't have to tab through the whole site to find what you are looking for
Yes, it is a shortcut to empower users who rely on keyboard only to use your application faster. That's accessibility: empowering users.
From a design perspective making sure your designs have enough contrast (especially text on a background) is often overlooked. From all the technical defaults (alt text etc. a developer can implement) we should also talk to designers about how they can make their designs more inclusive.
I've never really thought about accessibility before. Is there a good way for me to try experiencing a site from the perspective of an end user using a reader or something?
There are plenty of screen readers out there. One thing I do is to move around a page using the keyboard only. Start at the address bar, (or anywhere, really) and just see how far tabbing gets you!
Great article :)
Very useful guide to adding accessibility for your end users - something often overlooked!
Nice. Quick and easy. Tks
Awesome article Maria, thanks :)