Accessibility Tutorial

Internet is for everyone, but it won't be unless WE make it so.

Vint Cerf, 7. April 1999

A Brief History
The principle that everyone should be able to use the web equally, regardless
of any disability, is as important today as it was twenty years ago. People
who have limited use of their arms, people who cannot hear or see well and
people who process information differently, should all be able to access and
use web sites and apps. Web technologies have many built in features for
accessibility, and we as web developers should know them so that we do not
exclude any of our users.

There is no precise starting point of the history of web accessibility. This

coming list of milestones is far from complete. This is a brief history to
introduce the basics.

Milestones
1995: Dr. Cynthia
Dr. Cynthia Waddel published a web design accessibility standard for the City
of San Jose’s Office of Equality Assurance. One of the requirements in the
standard was that all images must have alternative text. This is one rule that
is still valid today. Another requirement was that all pages should support
text browsers. That is not something we aim for any longer, even though text
browsers still exist.

Even though her standard became an important starting point for other well
known standards and guidelines, she is better known for the accessibility
testing software Cynthia Says.

1996: Bobby
The accessibility testing software Bobby was released a couple of years
before Cynthia Says. Bobby worked much the same way many of the current
testing tools are working. HTML code was tested against a set of rules, and
the results was a list of issues. Instead of a browser extension, that did not
exist back then, you uploaded a local HTML file.
1997: Web Accessibility Initiative (WAI)
The Web Accessibility Initiative started as a W3C project in 1996. This
initiative is mostly known for the Web Content Accessibility Guidelines
(WCAG). They also provide a variety of strategies and resources for web
accessibility.

1999: Web Content Accessibility Guidelines (WCAG) 1.0

Tim Berners-Lee founded the World Wide Web and wanted everyone to have
equal access to it. W3C released 14 guidelines and 65 checkpoints about web
accessibility. Many of them are still a part of the WCAG. We will get into more
details about WCAG in a later module.

2001: Wave
Another accessibility testing tool. First released by Dr. Len Kasday and then
taken over by WebAIM in 2003. Still a popular tool by many developers and
accessibility experts.

2005: Screen reader VoiceOver

Many blind people use a screen reader, a tool that transforms information on
a screen to speech. VoiceOver is a native screen reader for Apple products.
Today VoiceOver is the most popular screen reader for mobile devices and
the third most popular on desktop and laptop. VoiceOver was not the first
screen reader, not even close. It is a part of this brief web accessibility
history, because of the dominant market share on mobile devices. VoiceOver
is only for Apple products.

2007: Screen reader NVDA

Another popular screen reader was released as an alternative to expensive
screen readers like Jaws. In 2019 it became the most common primary screen
reader for desktop and laptops. NVDA is only for Microsoft Windows
computers.

2008: WCAG 2.0

The second version of the guidelines was an updated version of WCAG 1.0. It
categorized the guidelines into four principles: perceivable, operable,
understandable and robust.

2018: WCAG 2.1

This is the most used guidelines today, and the current version. This is what
organizations try to conform to. The updated version had new guidelines
about touch screens and mobile devices, as well as more guidelines about
cognitive disabilities.

Accessibility Diversity
Accessibility Semantic
Elements
Semantic elements = elements with a
meaning.
Provide the user a good way to navigate and interact with your site. Make
your HTML semantic. Semantics is about using the correct element in HTML.
There are approximately 110 elements in HTML 5.

Two of them have no meaning – <div> and <span>. They tell us nothing
about the content. They have no built in accessibility features, so we should
always check to see if any other elements are better suited. Example of
semantic elements: <form>, <table> and <article>. They clearly define
the content.

Look online

In this example from Uber, we have five elements:

● A heading
● A paragraph
● A button
● A link
● An image

These elements can be translated into HTML:

● <h2>
● <p>
● <button>
● <a>
● <img>

Is this correct? Even though Sign up to drive looks like a button, Uber has
used a <a> instead of a <button>. This is the code, a bit simplified:
 <h2>Get in the driver's seat and get paid</h2>

<p>Drive on the platform with the largest network of active

riders.</p>

<a href="/signup/drive/>Sign up to drive</a>

<a href="/en/drive/">Learn more about driving and delivering</a>

<img src="driver.jpg" alt="">

This is semantically correct. The button is coded as a link, because it behaves

like a link. It takes the user to another view. It does not matter that the link is
styled as a button, it is still a link.

The <button> element should be used for any interaction that performs an action on
the current page. The <a> element should be used for any interaction that navigates
to another view.

Angular Material, Button

Now that you have learned the basics of semantics, let us check which
semantic elements we have in our HTML toolbox. Next up, landmarks.

Accessibility Landmarks
Why
With landmarks, blind users using a screen reader have the ability to jump to
sections of a web page.

What
In HTML there are some semantic elements that can be used to define
different parts of a web page:

● <header>
 ● <nav>
● <main>
● <aside>
● <section>
● <footer>

How - Example from The White House

The front page of The White House is using landmarks. It consists of a
<header> at the top, a <main> containing all the main content and a
<footer> with some <nav> elements at the bottom.

One way to visualize landmarks is to use the tool Accessibility Insights. One
of the features is that it highlights the landmarks, as we can see in the
following screenshot.
Try it yourself. Download the browser extension Accessibility Insights and
turn on the landmark visualization. Is your favorite site using landmarks?

Roles
But wait, it shows banner, contentinfo and navigation. This is a bit
confusing. The reason is that each landmark element has a corresponding
role. We have not talked about roles in this course so far. We will get back to
this, but as a simplified explanation:

A <header> has a built in role of banner. This means that both <header>,
<header role="banner"> and <div role="banner"> are more or less
equivalent. For most cases, <header> will be sufficient.

The same is true for <nav>, which has role="navigation" built in. <main>
is easier, it has role="main". And then we have <footer> with its
role="contentinfo". Let us leave the roles for now.

More than one of each landmark

A rule of thumb is to only use one <main> per page. When we use more than
one type of landmark, like multiple <nav>s like in this example, we must label
each of them. This is done with the attribute aria-label.

In the footer of The White House, we have three <nav>s, each with an aria-
label, like aria-label="social navigation". This means that a screen
reader user can skip directly to the social navigation. A helping hand. Some
will say that to use the wording "navigation" as a part of the label of a <nav>
is redundant. There is no right and wrong, but aria-label="social" should
be fine.

The <aside> and <section> tags

Ever since the landmarks were introduced to HTML, developers have been
confused. Two of the elements that people find vaguely defined are <aside>
and <section>. Let us try to clarify a bit. The big difference is that an
<aside> is related to the main content and the <section> is not related.
The contact page of The White House uses both an <aside> and a
<section>. The three sharing buttons are inside an <aside>. This makes
sense, they are related to the main content. If you use them, you will share
the page you are on.

The Stay Connected is a <section>. Good. It is not related to the main

content, and no other landmark will be appropriate. One improvement that
The White House can do with these landmarks is to add labels. This will be
better for a screen reader user. <section aria-label="Newsletter"> and
<aside aria-label="Share this page"> would be helpful.

Accessibility Buttons & Links

Why
Buttons and links are specific types of interactive components. Each of them
work differently with assistive technologies. The correct use of each
component helps users with assistive technologies to interact with the
component.

What
The <button> element should be used for any
interaction that performs an action on the current page.
 The <a> element should be used for any interaction that
navigates to another view.

Angular Material, Button

How
In the introduction, we saw that the visual design does not dictate which
HTML element we should use. A link that looks like a button, but behaves like
a link, is an <a>.

Both the "button" Sign up to drive and the link underneath is coded as an
<a>. So when should we use a <button>, then?

Let us take a closer look at the website of Uber. The first section of the
header has five elements – a logo, a dropdown menu and three links. One of
them is coded as a <button>.
Clicking Company opens a drop down menu. This is an interaction that
performs an action on the current page. Using <button> here is the correct
thing to do. The underlying links, About us, Our offerings and so on, are
correctly coded with <a> elements.

The arrow indicates that this is a button with a dropdown menu, that changes
direction when opened. This is a nice extra visual cue.

One benefit with this, is that semantic HTML gives context to screen readers,
which read the contents of a page out loud. You will learn more about screen
readers in module 7 about assistive technologies.

In this case, a <div> is wrong. Why?

● Buttons have more suitable styling by default.

● A screen reader identifies it as a button.
● It is focusable.
● It is clickable.

Both a link and a button are accessible for people relying on keyboard-only
navigation; it can be clickable with both mouse and keys, and it can be
tabbed between using the tab key on the keyboard.

Now you know when to use a <button> and when to use an <a>. What else
should you keep in mind?
 Proper links
Links take users from one page to another, or sometimes to another part of
the page. For a link to be accessible, remember to:

● Use the href attribute to specify the link destination.

● Use a proper URL in the href attribute. The URL can be absolute or
relative. https://uber.com/about is an absolute URL. /about is a relative
URL.
● Not simulate a link with other elements like <span> or <div>.
● Open the link in the current window. It is not recommended to open
links in a new window.

The link About us from the Uber example is coded like this, a bit simplified:

<a href="/about/">About us</a>

This is a proper and healthy link.

Accessibility Role, Name &

Value
Why
User interface components need a role, a name and sometimes a value, to
ensure that people using assistive technologies are able to use them.
Examples of assistive technologies are screen readers, switch controls and
speech recognition software.

What
There are two cases where we can't use a good HTML element with built-in
accessibility features, even though we want to:

● There is no native HTML element for what we are trying to achieve.

● There are technical limitations that prevents us using the semantically
correct element.
In both cases, we need to build a custom control. An important accessibility
principle is that a custom control needs a role, a name and sometimes a
value.

How
How do we make sure that custom components have a role, a name and a
value?

Role

In our last section, Button and Links, we learned that a dropdown menu
button should be coded as a <button>. What if our framework does not allow
us to do that? If it forces us to use an <a> instead? If the navigation
component in the library we are using, is built with <a>s? Then we need to
add a role.

This is done with the role="button" attribute. Now users of assistive

technologies can understand what the custom control is. A <button> has the
role="button" built in, so to write <button role="button"> is redundant.

Name
The custom control needs a name. In our example, the name is the content of
the element, Company. As long as we have written our element like <div
role="button">Company</div>, we have a good name. This is also known
as the accessible name. The accessible name for our <div> is Company.
Good.

That was too easy. In the following login form, we have several components –
a logo, a heading, a label, a dropdown, an input and a button.
We are taking a closer look at the label, dropdown and the input. Visually
there is no clear distinction between the dropdown and the input. The
dropdown is coded with a <select>, which is a correct element for this case.
However, it has no name:

<select name="countryCode">…</select>

It has a name attribute. This is not the same as an accessible name. This is
confusing. The article What is an accessible name? explains this further. The
name attribute is for computers. In a <form>, it is used as a reference when
the data is submitted. This name countryCode will not help any users. It will
not be picked up by assistive technologies.

To give this <select> an accessible name, we must use the attribute aria-
label. Normally, we would have connected a visual label to the <select>
component. In this case, there is only one visual label for both the
components.

This is a <select> with an accessible name:

<select aria-label="Country calling code" name="countryCode">…
</select>

Value
Some components have a value or a state. An accordion is open or closed.
This information has to be accessible.

An accordion is considered a custom component. There is no standard HTML

element to use here. Each accordion header should be a <button> or
role="button":

<div role="button">When do I get charged for a ride?</div>

Good. It has the role of a button. It also has a name, the content of the div.
To give this button a value, we need to tell assistive technologies that it is
closed. This is done with aria-expanded="false":

<div role="button" aria-expanded="false">When do I get charged

for a ride?</div>

Now, our accordion header has a role, name and a value.

Accessibility Color Contrast
Why
Text and graphical components on a web page need good contrast so that we
make sure that it is perceivable for users. Some of us have reduced vision.
Others will be in a situation where contrast is important, like out in a bright
sunlight.

What
We measure contrast between text or graphics against the background color.
This is called contrast ratio. A white text on a white background has a
contrast ratio of 1. This is impossible to perceive. Black text on a white
background has a contrast ratio of 21.

There is no perfect ratio. It is not always as high as possible, even though a

high contrast is usually more readable than a low contrast. According to
Apple, we should strive for a minimum of 4.5, although 7 is preferred.

How
One way to measure the color contrast is to use a tool like Contrast Ratio.
This accepts multiple color inputs, like RGB, HSL and hex. It even supports
transparency, like RGBA.

ADVERTISEMENT
Example from Foodora

Foodora uses the color Royal Red as their main profile color. The color has
the hex code #D60265. On white, the color contrast is 5.17. This is good for
decorations, icons, logo and buttons. If Foodora had used this color for bigger
chunks of text, the readability would have been poor.

Text on images
To measure contrast on text on top of a background image, we need to find
the brightest or darkest part of the image. If the text is bright, look for the
brightest part and vice versa.

In this example from Wolt, we have white text on a bright background image.
Using a color picker on a light green section gives us the hex value #a1ad95.
This is a contrast ratio of 2.35. Not sufficient. One possible improvement is to
add a color overlay on that part of the picture with text. The overlay can be
solid or have a degree of opacity.
Different states
Any interactive component has different states – hover, focus, active,
unvisited, visited and deactivated. Remember to ensure that the states also
have good contrast. Working with states, we have to think about two
scenarios:

● Color contrast needs to be good for all states.

● Change of contrast from unfocused to focused state is at least 3.
In this example from Cos clothing, the navigation has a color contrast of 9.73.

However, hovering Women gives us a hover contrast of 2.84.

Accessibility Color Alone as

Meaning
Why
Not everyone perceives color the same way. Red-green color blindness is the
most common form, it affects up to 8% of males. Some use grayscale mode
to curb their phone addiction.

What
Do not use color as the only visual indicator of a meaning.

The most common example of this is to style links without underline or

border.

Browsers underline hypertext links by default. It is possible to

remove the underline using Cascading Style Sheets (CSS), but this
is a bad idea most of the time. Users are accustomed to seeing
links underlined.

WebAIM: Links and Hypertext

Wikipedia is one example where color alone is used for styling links. In the
grayscale version of the site, it is not possible to see what is plain text and
what is a link.
How
Underlined links
Add underline to links. Or, do not remove them. Keep in mind that they can
reduce readability.

This modified version

of Wikipedia has links with underline. Some will say that this is visual noise
that reduces readability.

To improve readability, we can use CSS properties like text-underline-

offset and text-decoration-color.
 This modified version
is using text-underline-offset and text-decoration-color to improve
readability.

Color as status
Add text and/or icons to communicate meaning, in addition to color.

Tools
Note: The following tools gives a rating for the contrast assuming that you are using it
as text color.

Many combinations that are not suitable as background/color combinations, are

perfectly usable as colors for graphics, buttons, etc.

The tool Contrast Ratio uses color to communicate if a color contrast is good
or not. Red means bad contrast. In this example you might say that the
number is another indicator. That is a valid argument. However, you are then
assuming that the user understands the metric contrast ratio and knows
about the guidelines.

The tool Coolors Color Contrast Checker uses three methods to tell us
whether or not a color combination is good:
 ● The red color tells us that the contrast is bad.
● The text Very poor tells us that the contrast is b… very poor.
● 1 of 5 stars tells us that this is really bad.
●

Accessibility Meaningful &

Decorative Images
Why
Screen readers will ignore decorative images. Screen readers will try to speak
the meaning of a meaningful image.

What
Some images are meaningful and some are decorative. This is an important
distinction in terms of accessibility. Every image must be coded as
meaningful or decorative.

How
You will learn how to separate meaningful from decorative images.

Decorative images
If an image is not important for a user to understand the functionality or the
content of a web page or app, it is considered decorative. Can you remove it
with no impact? Then it is a decorative image.

Empty alt attribute

The basic way to set an image as decorative is to use an empty alt attribute.
On the front page of Alibaba, we have four shortcuts – All Categories,
Request for Quotation, Online Trade Show and Personal Protective
Equipment. Each has an illustrative icon. The shortcut All Categories has an
image showing three dark blue squares and an orange circle. This image is a
decorative image. We set this by adding an empty alt attribute:

<img src="Ha50044a3568449409f3396e5b36be8c3h.png_80x80q80.jpg"
alt="">

Assistive technologies, like a screen reader will then ignore the image.
Without the empty alt attribute, a screen reader may read the file name.
This will make no sense, and will confuse the user.

Background images
Another method for decorative images is to add them using the CSS
background-image property. This is common when we create hero images.
Font icons

At the bottom of the mobile version of Alibaba, we have five links that are
combinations of icons and text – Home, Feeds, Messenger, Cart and My
Alibaba. Since the site is still readable if we remove the icons, they are
decorative. The icons are created with font icons. No <img> element and no
background image. Add role="img" and aria-hidden="true":

<i class="navbarIcon" role="img" aria-hidden="true"></i>

With this code, we add some semantics to the <i> with the image role. User
agents now understand that this is an image. Screen readers also understand
that they should ignore the image.

Inline SVG images

If you add a decorative SVG image with the <img> element, you must add an
empty alt attribute as described. SVG images are often inserted inline, using
the <svg> element. In this case, aria-hidden="true" will make your image
decorative.

<svg aria-hidden="true" …></svg>

Meaningful images

Most of our images are meaningful. In this example from Alibaba, we have six
images:

● Logo
● Search icon
● Coffee
● Jacket
● 1 year badge
● Gold badge

The only decorative image here is the search icon. This is decorative because
of the text Search Products. If the icon for open search had been stand-alone,
it would have been a meaningful image.
 As with decorative images, we have several methods for coding meaning
images.

Descriptive alt attribute

The alt attribute provides an alternative text for an image, if the user for
some reason cannot view it. The reason can be a slow connection, an error
with the image file, or if the user uses a screen reader. The value of the alt
attribute should describe the image, or even better: the intention of the
image. You will learn what to write in the page Descriptive texts for images.

In this example from Alibaba, the logo is there for two reasons. First of all, to
tell the users which site they are on. Second, to provide the users a link back
to the front page.

Inaccessible:

<img src="TB1hVGkvVP7gK0jSZFjXXc5aXXa-365-49.svg">

Better, but still bad:

<img src="alibaba-logo.svg">

Better:

<img src="alibaba-logo.svg" alt="Alibaba logo">

Best:

<img src="alibaba-logo.svg" alt="Home of Alibaba">

Background images, font icons and <svg> images

The method are the same for both background images, font icons and <svg>:

● Add role="img"
● Add a descriptive aria-label or aria-labelledby attribute.
<div role="img" aria-label="Private house, modern
architecture. Minimalistic with a big garage.">

Now you know how to code decorative and meaningful images. Next you will
learn what to write as descriptive text for meaningful images.

Accessibility Descriptive Texts

for Images
Why
From the previous page, you learned that meaningful images need
descriptive texts. In this page you will learn what to write. The alternative
text for an image is for users that for some reason cannot view it. The reason
can be a slow connection, an error with the image file, or if the user uses a
screen reader.

What
The value of the alt attribute should describe the image, or even better the
intention of the image.

How
You will learn how to add descriptive text for non-interactive images, stand-
alone icons and logos.

Non-interactive images
Imagine you were to explain a web page over a phone call with a friend, what
would you say about an image? This is a good technique for writing
descriptive image texts.

Editorial images
In this screenshot from an article on Medium, there is an image of Google
cofounder Sergey Brin, jumping out of a helicopter. An descriptive text for
this image would be something like:

"Sergey Brin skydiving from a helicopter"

Product pictures
The first product image shows a bag of coffee. When zoomed in, there are a
lot of interesting details in the image, like the brand name, the weight and
the sustainability badge on the back.

An appropriate alternative text for this image would be:

"Dr. Nam whole bean coffee. Medium roast. 500 grams. UTZ certified"

The second product image shows a jacket. Try to make a brief description like
this:

"Kicker Sports men's jacket. Full zipper. Gray arms. Black and white pattern
in front. Two pockets with buttons on the sides."

Background images
Background images are often not meaningful. They can be used to set a
mood. Sometimes they tell something more than just a mood. Let us try to
add a text alternative for what the image is trying to tell us.
This example from Caledon Build has a background image of a house. Not an
ordinary house, but a modern house that this company built. The text
Building the next level does not tell the user specific what kind of houses
they build. A description of this image should be something like:

Private house, modern architecture with straight lines. Minimalistic with a big
garage

Stand-alone icons
Describe the function of the icon, not the presentation.
Articles on Medium have four stand-alone icons below the main heading.
Instead of describing the presentation of the icon, like "Twitter logo", we
should write what the icon does:

● "Share on Twitter"
● "Share on LinkedIn"
● "Share on Facebook"
● "Bookmark on Medium"

Badges
The previous example has an icon showing a small star. The icon is not
interactive, it does not do anything. It means something. It signifies partner
stories, readable only by subscribed members. A text description like "Black
star" would make no sense. Instead, write the meaning:

"Partner story"
The coffee product has two badges. For these we must add a text of what
they represent. The first has the text 1 YR. In this case, this means that the
supplier has been a paid supplier member for one year. The second badge is
an illustration of two yellow blocks. This icon is for gold suppliers that have a
premium membership. These badges should have alternative texts like this:

"Paid supplier for one year"

"Gold supplier"

Logos
Describe the intention of the logo.
In this screenshot from an article on Medium, we have two logos. First, the
main logo from Medium. Second, the logo of this channel, Business Insider.
To add "Medium" and "Business Insider" would not be sufficient as descriptive
text. The user might not know if the logo is linked to the web site of Business
Insider or to the Medium channel for Business Insider. In this case it is the
latter, and we can write these descriptions:

● "Medium home"
● "Business Insider on Medium"

Accessibility Link States

Why
Different link states help users interact with the links. A visited state can help
a person with short-term memory loss to understand which content has been
read. A hover state can help a person with reduced muscle control to know
when to click. A focused link helps keyboard users to know which link they
are about to activate.

What
Links hardly needs an introduction. They are the heart of the web. A link has
many states. Here are five of the most common states. In CSS terms, these
are pseudo-classes:

● Unvisited
● Visited
 ● Hover
● Active
● Focus

How
To make sure that all link states are accessible, we must remember these
three tips. We will use an example from the front page of ICRC, the
International Committee of the Red Cross.

1. Underline
Links are underlined by default. Removing the underline from a link in body
text is a bad idea most of the time. We learned this in the section about color
alone. This is most important for unvisited and visited links.

In the example from ICRC, there is one link in the body text – rules of war.
Without underline. Let us remove the text-decoration: none; from the
stylesheet:

Now the link is accessible to people with color blindness.

2. Contrast and focus

All states must have sufficient contrast, as we learned in color contrast. In
addition, a focused link must have sufficient contrast to the unfocused state.

Now the link rules of war is in a focused state. The text has an orange outline
without any offset. This focus state has two problems. First, the orange
outline has low contrast compared to the white background. Second, the lack
of offset makes the text hard to read. Let us use the red color that is already
in the color palette of the site, and let us add some offset.
Much better! A focused link that is accessible for people that are using a
keyboard to navigate and/or has reduced vision.

This improvement used the CSS properties outline-color and outline-

offset.

3. Hover
A clear hover state is helpful for everyone, especially people with motor
impairments.

In the footer of ICRC you can see a collection of quick links. They have a very
subtle hover state, changing the color from light grey to white. This effect can
be improved.
In this example we have added one effect for the hover state, bold text. It is
now clearer what action the user is about to do.
Accessibility Link Text
Why
People with visual disabilities may zoom the page so that they see a small
portion of the screen. There are many types of visual disabilities. One eye
condition is Glaucoma, one of the leading causes of blindness for people over
the age of 60. Some compare glaucoma to looking through a straw.

What
An accessible link text is a text that makes sense without any context. A link
text should explain clearly what information the reader will get by clicking on
that link.

How
Some examples of good and bad link text.

Good
● Find out more about the HTML language
● Read more about how to eat healthy
● Buy tickets to Mars here

Bad
● Click here
● Read more
● Buy tickets to Mars here
Another reason is that Google Search prefers descriptive links.

Write link text using descriptive phrases that provide

context for the material that you're linking to.
Google developer documentation style guide: Link Text
This example from ICRC (International Committee of the Red Cross) has three
links:

● Donate
● Read more
● Visit the eshop

As you can see from this list, the second link does not make any sense
without the context. It takes the user to the page Humanitarian Law and
Policy. An improved link text will be Law and policy. Or Read more about
humanitarian law and policy. Or somewhere in the middle.

Now we have a link text that is clear for the user.

Accessibility Headings
Introduction
In our introduction to semantic elements, you learned to use the heading
elements.

A heading is text that describes the content that follows

it.

—The Paciello Group, Headings & Accessibility

What you might not know, is that headings are important for accessible
navigation. Sighted users scan a web page to understand the structure of the
page. The same way, screen reader users use headings to navigate and scan
the page.

The headings must be clear, both visually and use clear wording. The heading
structure of a page forms the outline of the page. You might think of this like
the skeleton of the page.

News papers use a lot of headings. The front page of The Straits Times has
over 80 headings.

All these headings form an outline.

This is a good document outline. The levels make sense. The text is clear.

In the next module you will learn about assistive technologies and screen
readers. As a teaser, you should watch Rob Dodson from Google demonstrate
the importance of headings when using a screen reader. The first five
minutes of the video explains the use of headings in a screen reader.

Accessibility Heading Levels

Why
People use the heading structure to scan the page and get an understanding
of the main content. This is true for both sighted users and screen reader
users.
What
Headings are defined with the <h1> to <h6> tags. Users skim your pages by
its headings.

It is important to use headings to show the document structure and the

relationships between different sections. <h1> headings should be used for
main headings, followed by <h2> headings, then the less important <h3>, and
so on.

How
Let us check a good and a bad example of heading levels.

Good document outline: The Strait Times

1. Download the browser extension Web Developer. It is available for
Chrome, Firefox and Opera.
2. Open The Straits Times.
3. Open Web Developer. Under the tab Information, click View Document
Outline.
4. Scan through the document outline.
Now you have an understanding of how a document outline can be.

Bad document outline: The New York Times

1. Open The New York Times.
2. Open Web Developer. Under the tab Information, click View Document
Outline.
3. Scan through the document outline.
Problems
This document structure is confusing. It has many problems:

● No main heading <h1>.

● The first three <h2>s are confusing without the visual context.
● The <h3>s are not related to the above <h2> about Trump is not
related to the DealBook Policy Project.
● The <h3> has multiple headings combined.
● The <h3> is repeating information.

Take a look at the visual hierarchy.

The most prominent headline is Trump Acquitted. The next heading is 7

Republicans Break With Former President in Vote on 2nd Impeachment.
Visually, the next three headings are clearly subheadings on the same level,
even if Most Bipartisan … is larger than Analysis …

Solutions
Let us solve each problem, point by point.

No main heading

We have at least four alternatives to set the main heading:

1. Use the logo as the main heading. The way The Straits Times did it.
2. Use Trump Acquitted as the main heading.
3. Use Trump Acquitted together with 7 Republicans Break With Former
President in Vote on 2nd Impeachment as the main heading. Even
 though the two headings are distinct visually, they can be considered
one heading from a semantic point of view. They both describe the
content that follows.
4. Add a hidden heading Front page.

There is no right and wrong here. As the front page of a newspaper, it makes
sense to use the logo as the main heading. Remember to have an alternative
text for the image.

Confusing h2s

These three headings are confusing without the visual context:

● Listen to 'The Daily'

● Opinion: Listen to 'Sway'
● DealBook D.C. Policy Project

We can solve this in at least two ways:

1. Add a hidden heading.

2. Change the level of the headings from h2 to h3.
3. Change the headings to a list.

Sometimes it makes sense to add content just for screen readers. This is such
a case. A common practice is to use a CSS class .sr-only, where sr means
screen reader:

<h2 class="sr-only>Briefings</h2>

and add this styling to put it off screen:

CSS class .sr-only that is only accessible for screen readers:

.sr-only {

position: absolute;

left: -10000px;

top: auto;

width: 1px;

height: 1px;
 overflow: hidden;

Then it makes sense to change the level of the briefings from h2 to h3. But
are they really headings? Do they present the following content? Let's say no.
If we agree on that, we can change the three links to a list.

The Trump <h3>

Both the prominent heading Trump Acquitted and the following heading 7
Republicans … points to the same article. Therefore, they can be a part of the
same heading. Again, there is no right or wrong here. We can change this to
a h2 or we can add a hidden heading for this <section>:

<h2 class="sr-only">Headlines</h2>

The heading Headlines works well together with Briefings in the document
outline.

Repeating information

The heading 7 Republicans … is repeated twice. This is because a h3 is

nested inside another h3. Let's remove it and head over to Web Developer to
display our new document outline.
Way better.

In this page, you have read many headings. Check the document outline. Is it
good?

Accessibility Keyboard and

Assistive Technologies
Introduction
People with disabilities use technology in a variety of ways. Here are some
examples:

● People with hand tremors cannot grip a mouse. They use the keyboard
to navigate.
● People with mobility disabilities use their voice to control the computer
or mobile device.
● People with mobility disabilities use eye tracking to move the screen
cursor.
● People with mobility disabilities use switch devices to operate the
computer or mobile device.
● People who are blind use screen readers, braille displays or speech
recognition software.
● People with low vision use screen magnification.

The term assistive technologies is a broad term for all these tools. As
developers, we do not need to code for a particular technology. We use
standards methods to make sure that our solution is accessible for all.

In this module, you will learn the basics of keyboard and screen reader
navigation.

Accessibility Visual Focus

Why
Visual focus is crucial for all users that rely on keyboard and switch devices.

What
You learned a bit about visual focus when we talked about link states. Let us
dig deeper. Visual focus is sometimes called keyboard focus or tab focus. It is
a visual indicator on a interactive component that has keyboard focus. The
effect is often a border or outline.

How
You will learn not to remove the focus, and two options for styling the focus.
Do not remove or hide the focus
This is the most important takeaway from this module. Whatever you do, do
not remove the focus. This CSS line is ruining the accessibility for a lot of
people:

outline: 0;

Another common method for hiding the focus that the parent element is to
small to show it, in combination with:

overflow: hidden;

Most browsers use the outline property to show the visual focus of an
interactive element. We have two options. Leave it or customize it. Removing
it is not an option.

In this example from Airbnb, the destination Ålesund is the focused element.
However, it is not possible to tell. The reason is that the parent <div> has
overflow: hidden;

Option 1: Use the default

The easiest way to handle visual focus is to leave it for the browser to handle.
This has many benefits:

● Users that rely on the visual focus, recognize it easily.

● You don't have to code anything.
● Users don't get any surprises.

Removing the overflow: hidden; showing the default focus styling. The
browser Chrome in mobile mode is using an orange outline. You might think
that keyboard focus is not important on mobile devices. That is a
misconception. People use keyboards and other assistive technologies on
mobile devices as well.

Option 2: Customize the visual focus

We also have some challenges with the default focus.

● The default styling may not align with the color palette of the site.
● The default styling is similar to the color palette of the site.
● The default styling is not visible enough in all browsers.
The travel site Momondo has a vivid color palette. They can pick a color from
their palette to use as the visual focus.

This is a modified version of the Momondo website, showing the link Trips in
focus with a pink and white outline. The pink color is from their palette, the
same as the search button.

As a side note, the search button has insufficient color contrast when used
with white text. The contrast ratio is only 3.33. However, used as a visual
focus against a dark purple background the contrast is better with a ratio of
5.47.
CSS Outline
To better make custom visual focus, you need to know about the different
CSS outline properties. Head over to W3Schools to learn about the outline
style, color, width and offset. Now you are better prepared to make keyboard
accessible interfaces.

Accessibility Skip links

Why
People using keyboard, screen readers, switch controls and other assistive
technologies use skip links to reach main content or other important sections
easier and faster.

What
The most common skip link is the first interactive element on a page. It takes
the user to the main content, past the global elements like the logo, search
and navigation. It is almost always hidden until it receives focus.

How
 Try it yourself

1. Open the website WebAIM on your desktop or laptop.

2. Press the tab key.
3. Press enter to follow the link.

HTML
The HTML of a skip link is the easy part.

Let's assume that you have used a <header> and a <main> in your site, as
you learned in Landmarks. The skip link is a global element, so you should
include it in the <header>. You also need to have an ID on the <main>, so
that you are able to link to it with an anchor.

<header>

<a href="#main" class="skip">Skip to main content</a>

</header>

<main id="main">

That's it. No JavaScript. A link and an ID.

CSS
As you might noticed in the HTML, the link had the class skip, so that we are
able to hide it.

.skip {

position: absolute;
 left: -10000px;

top: auto;

width: 1px;

height: 1px;

overflow: hidden;

This code moves the link way outside of the browser. If you are not familiar
with absolute positioning, read about the CSS position property. The 1px size
and the overflow: hidden; are for special cases where user has
deactivated absolute positioning.

When the link is focused, it has to be visible. This is also done with CSS:

.skip:focus {

position: static;

width: auto;

height: auto;

This method is very helpful and important for users that rely on keyboard and
similar input. If you have a complex site, you might want to add more skip
links, not only to the main content. We will cover that later.
Accessibility Screen Readers
Why
Screen readers are necessary for blind people, important for partially-sighted
users and helpful for people with reading disorders.

What
It is hard to teach about web accessibility without talking about screen
readers. Screen readers has become for web accessibility what wheel chairs
is for accessibility. Even though it is a myth that accessibility is just for blind
or partially-sighted users, screen reader support is a mandatory topic.

If you have done everything you have learned in this course, your site should
probably work well in screen readers. That does not necessarily mean that all
blind users are able to use it.

As the name implies, a screen reader is a tool that reads your screen.
Necessary for blind people, important for partially-sighted users and helpful
for people with reading disorders.

Most common screen readers

You will learn the name of four different screen readers.

Mobile
For mobile devices, Apple has the biggest share of screen reader users. The
screen reader VoiceOver is built in on iOS. The second most popular is
TalkBack for Android, also built in on all Android devices.

Making sure your site works well with these two is a good starting point.
Before we proceed, read these articles:

● Get started on Android with TalkBack

● Turn on and practice VoiceOver on iPhone

Desktop and laptop

For desktop and laptop computers, there is two screen readers you should be
aware of – NVDA and JAWS. If you have to choose one for testing, go for
NVDA. It is free and its popularity is growing. Both are only available for
Windows.

How
You will to set the language, and we will test two websites – Toyota and
Hyundai.

Language
For the screen reader to speak the correct language, it needs to know what
language your content is. This is done with the lang attribute in the <html>
element. The following example specifies English as the language:

<!DOCTYPE html>
<html lang="en">

1. Check the source code of the english Wikipedia article about Dyslexia.
2. Click the language Bahasa Indonesia.
3. Check the source code again.

The lang attribute changed from lang="en" to lang="id". Good for screen
readers and good for search engines.

Language of parts
Sometimes parts of your content is in another language. To make screen
readers change their language in the middle of the page, we use the same
lang attribute. Check the source code of the link to Bahasa Indonesia on the
english page about Dyslexia:

<a href="https://id.wikipedia.org/wiki/Disleksia" lang="id"

hreflang="id">Bahasa Indonesia</a>

Now the screen reader understands that the words "Bahasa Indonesia"
should be read in the language Bahasa Indonesia, not English. It also
understand that the target page is in Bahasa Indonesian because of the
hreflang attribute.

Screen reader testing

Let's scratch the surface of screen reader testing. In this course, we will not
dig deep. Screen readers is a big topic. Use your phone to follow these two
examples. You might not hear exactly what's written here, there are many
factors that affect the screen reader output.

Toyota

1. Open toyota.com in your browser and turn on TalkBack or VoiceOver.

On Android, use Chrome. On iOS, use Safari.
2. Swipe from left to right, to reach the first element on the front page.
You will hear something like "Skip to main content …". Good, a skip
link!
3. Swipe to the next element. "Toyota link main-navigation-bar …". A bit
confusing? "Toyota" comes from the SVG with the
<title>Toyota</title>.
4. Swipe to the next element. "Button". What does this button do? We
have no idea.
5. Next. "Button". What?
6. Next. "Button". Let us give up.

After hearing the logo, you probably got lost. Three buttons without
accessible names. As you learned in the page Role, Name and Value, all
elements must have an accessible name.

How to improve this experience

1. Better label on navigation landmark. As you have learned in
Landmarks, you must use aria-label if you have more than one of
each landmark. Toyota has more than one <nav>, so they have used
aria-label like they should. However, the value of the attribute
should be written for humans without hyphens. <nav aria-
label="main"> would be better.
2. Better link name on logo. As you learned in Link Text, a link text should
explain clearly what information the reader will get by clicking on that
 link. This can be improved by using aria-label="Toyota front
page" on the <a>.
3. The first "Button" is a <input type="button"> without an accessible
name. It opens a modal asking for a zip code to find Toyota dealers
nearby. This can be fixed by using aria-label="Enter zip code to
find a dealer nearby" on the <input>.
4. The second "Button" is related to the zip code button. It has a
geolocation icon. From an accessibility point of view, these two
elements should be merged into one.
5. The third "Button" is the hamburger icon. A aria-label="Open menu"
would make this accessible.

These small changes would improve the Toyota site, not fix it. Using
components like modals and menus requires other considerations as well.
This course will not go into details about custom components. If you want to
learn more about patterns like these, please visit WAI-ARIA Authoring
Practices 1.1 to read about menu button, modal and carousel.

Hyundai

● Open Hyundai Worldwide turn on your screen reader.

● Swipe from left to right, to reach the first element on the front page.
"Go to menu". Good, a skip link!
● Swipe to the next element. "Hyundai World Wide". Probably the page
we are on.
● Next. "Hyundai, link image". Probably the logo.
● Next. "Go to global distributors page, button". We understand this, but
is it a button?
● Next. "Go to channel Hyundai page, link". Understandable.
● Next. "Search, button". Perfect.
● Next. "Menu, button". Great.
Overall, the top part of the page is accessible for screen reader users. The
following tips are small improvements.

How to improve this experience

1. The "Hyundai World Wide" is a <span> for screen readers only. It is
visually hidden. The intentions is to tell the user the title of the current
page. This is redundant because of the <title> element and can be
removed.
2. Better alt text on logo. Include the intention of the link: alt="Hyundai
World Wide front page".
3. Strip down the accessible names on links and buttons. Remove "Go to"
and "page". Global distributors is enough.
4. Use <a> instead of <button> on the Global distributors link, as we
learned in Buttons and Links.

Now you have learned the basics of a screen reader. Feel free to explore
other accessibility options built in your mobile device. Try to operate your
phone with your face, using switch controls.

Accessibility Forms Introduction

An HTML form is used to collect user input. This module will teach you how to
make accessible forms. We will cover the basic form elements like <input>,
<label>, <fieldset> and <select>, not custom form components.

Forms come in a variety of ways. From simple search forms to order forms
and complex multistep forms.

Accessibility Labels
Why
Labels are critical for blind users, user with low vision, users with mobility
disabilities and users with memory loss. Missing labels will make a form
inaccessible for many users.

What
Visual labels are text near a form control that describe what information
belongs in a given form field or a group of fields. Each label must be
programmatically associated with the form control or group of controls.
Labels are not necessarily the <label> element.

How
You will learn how to use <label>, aria-label and <legend>.

The <label>
The <label> tag defines a label for several elements, like <input>,
<select> and <textarea>.

In this example from Vodafone, we have one <select> and one <input
type="email">, each with a describing <label>:

<label for="customerType">Who are you buying for

today?</label>
<select name="customerType" id="customerType">

Notice the use of the <label> element in the example above.

The <label> element is useful for screen-reader users, because the screen-
reader will read out loud the label when the user focus on the input element.

The <label> element also help users who have difficulty clicking on very
small regions (such as radio buttons or checkboxes) - because when the user
clicks the text within the <label> element, it toggles the radio button or
checkbox.

The for attribute of the <label> tag should be equal to the id attribute of
the <input> element to bind them together.

Required fields
Form labels often contain a "*" or the word "required" to indicate that the
field is required. Both of these methods are fine. However, it is recommended
to add the required and aria-required="true" to the form control if you
use an asterisk (*):

<label for="email">Your email address <span

class="mandatory">*</span></label>
<input id="email" name="email" required aria-required="true"
placeholder="Email" required="">

The aria-label
Fields without visual labels still needs a label. If you can not use a <label>,
one option is to use a aria-label.
This search field has a placeholder, but no label. A placeholder is not a valid
accessible name. You can not rely on it as a substitute. An easy solution here
is to add aria-label="Enter search term":

<input placeholder="Enter search term" aria-label="Enter

search term">

The <legend>
Groups of form controls, like checkboxes and radio buttons often require a
higher level of "label" in addition to the <label>. This high level "label" is
made with <fieldset> and <legend>.

This registration form has three form controls to provide the date of birth.
Visually it makes sense that both day, month and year is related to "Your
 date of birth". This relation is not obvious for a screen reader user. We can
not use <label> here. The labels are Day, Month and Year. The solution is to
add a <fieldset> and a <legend>:

<fieldset>

<legend>Your date of birth</legend>

<label for="dobDay">Day</label>

<select id="dobDay">…</select>

<label for="dobMonth">Month</label>

<select id="dobMonth">…</select>

<label for="dobYear">Year</label>

<input id="dobYear" type="text" placeholder="YYYY">

</fieldset>

Want to make efficient forms? Learn about autocomplete.

❮ Previous

Next ❯
Even this simple search field is a form.

The most important element to make sure your form is accessible is a label.
Not necessarily a <label>. What is the difference, you might wonder?
Continue to learn about labels.

Accessibility Autocomplete
Why
The autocomplete attribute makes a form easier and more efficient for all
users, especially users that are attention deficit, have cognitive impairments,
reduced mobility, low vision or blind users.
What
Have you ever experienced coming to a web form, and your browser autofill
the fields in magical way? That is either because the browser was smart, or
that the form author had used the autocomplete attribute in correct way.

This is convenient for everybody. This is very helpful for user with motor
impairments or cognitive disabilities. Filling a form can be hard, and the
autocomplete attribute is often a helping hand.

How
Autocomplete can be used on <input>, <textarea>, <select> and <form>
elements. The attribute has many possible values, like:

● "name": Daniel Zhang

● "given name": Daniel
● "family name": Zhang
● "organization": Alibaba Group
● "country-name": China
● "street-address": 699 Wang Shang Road

The complete list of values: Input Purposes for User Interface Components.

Example: A registration form

This registration form has fields for email and birthday. A great opportunity to
provide autofill. Many users have these details saved in their browser, ready
for an autocomplete enabled form. The browser needs to understand the
purpose of the fields.

A label and a placeholder is a hint for some browsers, but not a bulletproof
solution. The best way is to add the magical autocomplete attribute:

<input id="email" autocomplete="email" name="email" aria-

required="true" placeholder="Email" required>

<select id="dobDay" autocomplete="bday-day" aria-

required="true" required>

<select id="dobMonth" autocomplete="bday-month" aria-

required="true" required>

<input id="dobYear" autocomplete="bday-year"

placeholder="YYYY" aria-required="true" required>

Exceptions
No rules without exceptions. The above code example will make the form
easy, efficient, error free and accessible. If the form was asking for another
email, not "your" email, it would make no sense to add the autocomplete
attribute. When the data is probably not saved in the browser, it shouldn’t
have attribute.

Not all forms are error free. How do you code accessible error messages.
Read on!

Accessibility Errors
Why
Everyone make mistakes. When we do, we need to understand why we have
failed, to be able to correct ourselves. An accessible form needs error
messages that is perceivable and understandable for people who is color
blind, who is blind or low vision, and people with limited cognitive abilities.

What
An accessible error message is
 ● written in text. Color and icon can be used, but not alone.
● close to the element that has failed.
● informative, helping the user.
● associated to the failed element in the code.

In addition, is is helpful to move the focus to the form control that has failed.

In this registration form, the user has typed a number instead of characters.

How
You will learn five techniques for creating accessible error messages.

Written in text
The error message is written in text, in addition to a warning icon and red
border. Three different indicators makes this error situation clear to the user.
Only an icon and a red border would not have been sufficient for all users to
understand.

Close together
Design elements near each other are perceived as related, while elements
spaced apart are perceived as belonging to separate groups.
 Design elements near each other are perceived as
related, while elements spaced apart are perceived as
belonging to separate groups.

—Nielsen Norman Group, Proximity Principle in Visual Design

In this example the errors are close to the failing fields. In combination with a
big margin between the fields, it is easy to understand where the error
messages belongs.

Informative
The more informative, the better.

In our first example the error "Your first name must have at least two letters
and no unusual characters" is informative. It is written in a human language.
It can be improved, written even more precise:

"Your first name must have only letters, not numbers."

The more precise, the better. This means that the system needs more error
messages for different situations. Be pragmatic when deciding how many
different error messages and situations you will create. Ask the users if they
understand what is wrong. If not, write the error more precise.

Associated with the form control

But what about the code?

<input name="firstName" id="firstNameInput" type="text"

pattern="[^.]*?">

<p id="firstName-length-error" role="alert">Your first name

must have at least two letters and no unusual characters</p>

The error has the role alert. This is good. It would make a screen reader read
out the content, even though it is not in focus.

The error message is not assosiated with the field. This can be done using the
aria-describedby attribute. The value is the ID of the error message.

Also, we should add aria-invalid="true" on the invalid form control to tell

screen readers that the form control has failed. An improved version of the
input field:

<input name="firstName" id="firstNameInput" type="text"

pattern="[^.]*?" aria-describedby="firstName-length-error"
aria-invalid="true">

Move focus
This is more important for server-side validations, compared to client-side
validation. When the user submits a form, the focus moves to the first invalid
field.
In this example, all three fields have been invalid. The focus was moved to
the first field, First name. The error is removed when the user starts typing.

Accessibility Zoom Introduction

In this module, you will not learn about the video service Zoom. You will learn
about different ways users use zoom to better see and read the content of a
site or app.

Users with low vision zoom in on content to be able to perceive it. Users with
good vision zoom in on content to increase the readability of the content.
There are three main ways of zooming:

1. Screen magnifier
2. Text zoom
3. Page zoom
You will learn about text and page zoom. As a developer, there is not that
much to think about when it comes to screen magnifier.

This is an example of a screen magnifier from Mac OS X. The picture-in-

picture shows a 10 times zoomed portion of the Samsung website.

First, you will learn how to let users change the text size without zooming the
entire interface.

Accessibility Text Size

Why
Some people need larger text in order to perceive letters.

What
Users must be able to change the text size without zooming the entire
interface.

This is done in the settings of the operating system or the browser. There are
many ways of doing this. In the Chrome browser on desktop, you can set the
font size in settings under Appearance and Customize fonts.
How
Let us open the website for LG in India in the Chrome browser on a desktop
or laptop computer.

This is what the section Most popular looks like with default browser settings.

Browser settings
Now, in your Chrome browser, set the font size to 40 pixels. That is 2.5 times
the default size. For low vision users, this is not much.
.model-name {

font-size: 18px;

line-height: 22px;

height: 66px;

overflow: hidden;

text-overflow: ellipsis;

display: -webkit-box;

-webkit-line-clamp: 3;

-webkit-box-orient: vertical;

}
 Relative units
To solve this, let us try rem instead of px. 18 px is 1.125 rem if the base size
is 16 px.

.model-name {

font-size: 1.125rem;

line-height: 22px;

height: 66px;

overflow: hidden;

text-overflow: ellipsis;

display: -webkit-box;

-webkit-line-clamp: 3;

-webkit-box-orient: vertical;

}
 There are several reasons for this. First of all, the line-height is set in
pixels. As with font size, we should avoid absolute units when setting line
height. line-height can be set with a number without a unit, instead of a
length. In this case, we can use line-height: 1.2; instead of line-
height: 22px;

The container of the product title has height: 66px; – not a good idea when
you want to support text zoom. Let us try to remove that absolute height.

The last problem is that this product title has -webkit-line-clamp: 3; that
limit the text to three lines. Important information is lost.

.model-name {

font-size: 1.125rem;

line-height: 1.2;

overflow: hidden;

text-overflow: ellipsis;

display: -webkit-box;
 -webkit-box-orient: vertical;

Result

Finally, large and readable text.

This course will not cover all techniques for supporting text resizing. The
main takeaways are that you should test the sites you code, and strive to use
relative units.

Accessibility Page Zoom

Why
People with low vision need to zoom the content in order to use the page.

What
The big brother of text zoom is page zoom. Zoom everything! The principles
are easy to understand:

● Avoid horizontal scrolling.

● All content is available.
● All functionality is available.
● Avoid text in images.
● Provide space for key content.

Available means that nothing is clipped, truncated or obscured.

Page zoom often triggers mobile view on responsive sites, which is good.

How
You will now learn five techniques to support page zoom.

Provide enough space for key content

Do not let secondary content occupy the screen.

Hidden icons

In this example from Samsung India, the page is zoomed 400 %. The content
is scaling properly. No horizontal scrollbar. However, the chat button occupies
a big part of the browser window. It is not easy to access the buttons for
search, cart or menu. And the quality of the button graphic is low. In addition,
there is a huge ad for an app.

Improvements:

● Add a minimize button for the chat button. Use the minimized version
as the default.
● Use vector graphics like SVG instead of raster graphics like PNG.
● Show mobile ads only for mobile devices.

No clutter

In this example from Philips, the entire viewport is available for main content.
The main navigation is opened, and there is no clutter. The text and graphics
are scaled well.

The viewport is set:

<meta name="viewport" content="width=device-width, initial-

scale=1">

Learn more about responsive web design.

Avoid horizontal scrolling

Scrolling in two dimensions is confusing.

Fixed width
In this example from Dell, we can only see a small part of the header. The
site does not scale when zoomed. The result is a large horizontal scroll that
makes it hard to navigate the page in two dimensions.

In addition, the cookie consent button is fixed, not possible to remove even
though the consent is given. The logo and the icons are low resolution PNGs
that does not scale well. Viewport is not set.

Improvements:

● Make the site responsive.

● Add a minimize button for the cookie button. Use the minimized
version as the default.
● Use vector graphics like SVG instead of raster graphics like PNG.

All content and functionality is available

No content should be hidden when zoomed.

Hidden tabs
 In this example from Sony, the tabs with product information is not accessible
in a desktop browser with page zoom. Even if the user scrolls, the scrolling is
happening outside of the browser window. All the specifications, features,
reviews and support are inaccessible. The problem is that the entire section
is "sticky":

<section class="sticky-nav">

.sticky-nav {

position: fixed;

z-index: 1035;

top: 0;

This section is 159 pixels high in a mobile view. When zoomed four times, the
fixed section occupies 636 pixels of the desktop view. With a browser height
of 720 pixels, minus the top part of the browser, leaves not much room for
the main content.

Fixed content is not necessarily inaccessible. The takeaway is that you should
always test your site with page zoom in common browser sizes.
In a mobile view, the content beneath the tabs is accessible.
The sticky navigation from Huawei is not too high, so there are enough space
for the main content.

Avoid text in images

In this example from Xiaomi, the zoomed text is pixelated because it is part
of the image. Parts of the text is also outside the browser window, so that the
user has to scroll to read the entire product title. Displaying text with pure
HTML and CSS has many benefits, in addition to be accessible: responsive,
translatable and searchable.
15 HTML tags for accessibility

1. ARIA labels

The first rule of ARIA use is “If you can use a native HTML

element or attribute with the semantics and behavior you

require already built in, instead of re-purposing an

element and adding an ARIA role, state or property to

make it accessible, then do so.” Please refer to W3C for

the complete list of ARIA rules.

The aria-label attribute is used to define a string that

labels the current element. It helps assistive technology

attach a label, which is otherwise anonymous, to an HTML

element. You can use it in cases where a text label is not

visible on the screen, such as icons or buttons. For

example:
<button aria-label="Close">X</button>

If there is visible text labeling the element, you should use

aria-labelledby instead. This attribute references another

element that provides the label for the current element.

For example:

<span id="logo">Be Accessible</span>

<img src="logo.png" alt="" aria-labelledby="logo">

We can also use aria-describedby in our HTML. It is an

ARIA attribute similar to aria-labelledby that lists the ids

of other elements that provide additional description for

an element.

For example, if you have a text input that requires a

specific format, you can use aria-describedby to link it to a

hint element that explains how to enter the data correctly.

Here’s a code snippet:

<input type="text" id="phone" aria-describedby="phone-hint">

<span id="phone-hint">Enter your phone number with country code</span>

2. <fieldset> and <legend>

These tags are used to group related form controls

together and provide a caption for them. This helps screen

readers and users who navigate with keyboards

understand the context and purpose of each form control.

The <fieldset> tag creates a border around the group of

form controls, while the <legend> tag provides a title for

them. For example:

<fieldset>

<legend>Contact preferences</legend>

<input type="checkbox" id="email" name="email">

<label for="email">Email me</label><br>

<input type="checkbox" id="phone" name="phone">

 <label for="phone">Call me</label><br>

<input type="checkbox" id="text" name="text">

<label for="text">Text me</label><br>

</fieldset>

3.<label>

This tag is used to associate a text label with a form

control, such as an input field, a checkbox, or a radio

button. This helps screen readers and users who navigate

with keyboards identify what each form control is for. You

should use the for attribute to link the label with the

corresponding form control by their id attribute. For

example:

<label for="name">Name:</label>

<input type="text" id="name" name="name">

4. Role attribute

The role attribute describes the role of an element in

programs that can make use of it, such as screen readers

or magnifiers. It helps to provide semantic information

about the purpose of an element, especially when the

HTML element does not convey its meaning clearly. For

example:

<a href="#" role="button">Button Link</a>

This tells screen readers that this element is a button, not

a link. There are four categories of roles: abstract roles,

widget roles, document structure roles, and landmark

roles. You can find a list of all the roles and their

descriptions at MDN.

5. alt attribute with <img>

You should always provide an alternative text (alt

attribute) that describes the image content or function for

users who cannot see it. The alt text should be concise and

relevant, and avoid repeating information that is already

on the page. For example:

<img src="logo.png" alt="Be Accessible logo">

6. <h1> to <h6>

These tags are used to create headings for your content.

They help screen readers and search engines understand

the structure and hierarchy of your page. You should use

only one <h1> tag per page and use lower-level headings

in a logical order. For example:

<h1>HTML Accessibility</h1>

<h2>Semantic HTML</h2>

<p>Semantic HTML means using correct HTML elements for their correct

purpose as much as possible.</p>

<h3><button> Element</h3>

<p>The <button> element defines a clickable button that can

be used to trigger an action or submit a form.</p>

7. <table>, <th>, <tr>, and <td>

These tags are used to create data tables that display

information in rows and columns. You should use proper

markup to indicate table headers (<th>) and table cells

(<td>) within table rows (<tr>). You should also use

scope attributes to specify whether a header applies to a

row or a column, and summary attributes to provide an

overview of the table content for screen readers. For

example:

<table summary="This table shows monthly sales figures by product

category">

<tr>

<th scope="col">Category</th>
 <th scope="col">January</th>

<th scope="col">February</th>

...

</tr>

<tr>

<th scope="row">Books</th>

...

</tr>

8. lang attribute

The lang attribute specifies the language of the page or a

part of it. For example:

<html lang="en">

This tells our page that the language is in english.

9. tabindex

The tab index attribute specifies the order of keyboard

focus for elements. For example:

<a href="#" tabindex="1">First link</a>

If a user were to tab through our page, the HTML element

with tabindex=”1" would be the first in focus, and

tabindex=”2" would be the second in focus. If we use

tabindex=”0" then it follows the natural progression of

tabbing in the page. We can use tabindex=”-1" if we want

the element to be skipped over in tabbing.

10. <caption>

The <caption> tag defines a title for a table. The

<caption> tag must be inserted immediately after the

opening <table> tag, and it can only be used once per

table. An example for <caption> is:

<table> <caption><strong>Sales report for January 2023</strong>
</caption>

<tr> <th>Product</th> <th>Sales</th> </tr>

<tr> <td>Coffee</td> <td>$5000</td> </tr>

<tr> <td>Tea</td> <td>$3000</td> </tr>

<tr> <td>Milk</td> <td>$2000</td> </tr>

</table>

11. <figure> and <figcaption>

The <figure> tag defines a container for content such as

images, diagrams, code snippets or illustrations. The

<figcaption> tag defines a caption for the content inside

the <figure> element. The <figcaption> tag can be placed

either before or after the content within the <figure>

tag. The <figcaption> tag is not mandatory to be used

with the <figure> tag.

An example for <figure> and <figcaption> is:

<figure> <img src="logo.png" alt="Octobot logo">

<figcaption>The logo of Octobot</figcaption>

</figure>

12. <abbr>

The <abbr> tag defines an abbreviation or an acronym, like

“HTML”, “CSS”, “Mr.”, “Dr.”, etc. You can use the global

title attribute to show the description for the

abbreviation/acronym when you mouse over the element.

For example:

<p>The <abbr title="World Health Organization">WHO</abbr> was founded

in 1948.

</p>
This will display “WHO” as an abbreviation with a dotted

underline, and show “World Health Organization” as a

tooltip when you hover over it.

13. <button>

Use a native <button> or <input type="button"> whenever

possible, as they have built-in keyboard accessibility for

both Enter and Spacebar keys. If you use a different

element as a button, such as a <div> or a <span>, you need to

add role="button" and tabindex="0" attributes to make it

focusable and announce it as a button. You also need to

add JavaScript event handlers for both click and keydown

events to make your custom button work with mouse and

keyboard. Always provide a clear and descriptive text label

for your button, either inside the element or using the

aria-label attribute. Avoid using images or icons as buttons

without text labels, as they may not be understood by

screen readers.
Here is an example of a native button with an accessible

text label:

<button>Submit</button>

Here is an example of a custom button with ARIA

attributes and JavaScript events:

<div role="button"

tabindex="0"

aria-label="Close"

onclick="closeWindow()"

onkeydown="handleKey(event)">

<img src="close-icon.png" alt="">

</div>
<script>

function closeWindow() {

// code to close the window

function handleKey(event) {

if (event.keyCode === 13 || event.keyCode === 32) {

// Enter or Spacebar pressed

closeWindow();

</script>

14. <nav>

The <nav> element is used to mark up a section of a page

that contains navigation links. It helps users find and

traverse the different pages available on your site.

Some tips for using <nav> with accessibility in mind are:

● Use <nav> only for site navigation or intra-page

navigation, not for other types of links such as

social media icons or footnotes.

● Use an unordered list (<ul>) inside <nav> to group

your navigation links logically.

● Use aria-labelledby to label your <nav> element if it is

not clear from the context what it contains.

● If you have more than one <nav> element on your

page, use different labels for each one to avoid

confusion.

Here is an example of using <nav> with accessibility in

mind:
<nav aria-labelledby="main-nav">

<h2 id="main-nav">Main navigation</h2>

<ul>

<li><a href="home.html">Home</a></li>

<li><a href="about.html">About</a></li>

<li><a href="contact.html">Contact</a></li>

</ul>

</nav>

15. <audio> and <video>

The <audio> and <video> tags are HTML elements that

embed audio and video content on a web page. They can

be controlled by keyboard or mouse. However, they also

need some additional features to make them accessible for

users with disabilities, such as:

● Transcripts: These are text versions of the audio or

video content that can be read by screen readers

or displayed on the page. They should include all

the spoken words and relevant sounds or music in

the media.

● Captions: These are synchronized text overlays

that appear on the video screen and show what is

being said or heard. They should be accurate,

clear, and readable. They can be either open

(always visible) or closed (can be turned on or off).

● Description: This is an explanation of the visual

information in the video that is not conveyed by

the audio. It can be either integrated in the main

audio track (audio description) or provided as a

separate text track (text description). It should

describe important actions, scenes, characters,

and context.
 ● The <track> tag is used to provide additional

information for audio and video content, such as

captions or descriptions. It has a kind attribute

that specifies the type of information (captions or

descriptions), a srclang attribute that specifies the

language of the information, and a label attribute

that provides a name for the information. The

track tag also has a src attribute that specifies the

source file of the information, which is usually in

WebVTT format.

Here are some code examples of how to use <audio> and

<video> tags with accessibility features:

<audio src="podcast.mp3" controls>

Your browser does not support the audio element.

<track src="podcast.vtt" kind="captions" srclang="en" label="English">

</audio>

<video src="demo.mp4" controls>

Your browser does not support the video element.

<track src="demo.vtt" kind="captions" srclang="en" label="English">

<track src="demo.ad.vtt" kind="descriptions" srclang="en"

label="English">

</video>

Thanks for reading along so far! I will have additional

content creating HTML pages, and will further explore

design + code in future articles. Subscribe to see my

future posts! If there is an HTML tag that is important for

accessibility

HTML plays such a critical role in the structure of the web that it must be
universally accessible to users with disabilities. Following accessibility
standards and guidelines, including those outlined in the Web Content
Accessibility Guidelines
(opens in a new tab)
(WCAG), ensures developers create accessible HTML code that
accommodates diverse users.

Below, we’ll review HTML accessibility best practices for creating accessible
code and examine a list of HTML tags that improve accessibility and the user
experience.

What is HTML Accessibility?

HTML accessibility is the practice of designing and coding HTML elements to
ensure all users, including those with disabilities, can perceive, understand,
navigate, and interact with the content. The goal of HTML accessibility is to
remove barriers that might prevent people with disabilities from accessing
information or easily using digital content.

The Connection Between Semantic HTML and Accessibility

One factor that plays a critical role in enhancing HTML accessibility is
semantic HTML. Semantic HTML refers to using HTML elements that clearly
describe their meaning structurally rather than being used for presentation or
styling purposes.

More simply, semantic elements convey the intended meaning of the content
they enclose. For example, <button> and <form> are examples of semantic
HTML.

Semantic HTML helps developers create more meaningful and structured

content. This makes content more accessible and usable for all users,
especially those who rely on assistive technologies. Plus, semantic HTML
elements ensure web design elements are used appropriately, improving
content accessibility and inclusivity.

ARIA and Accessible HTML

Accessible Rich Internet Applications (more commonly known as ARIA) are a

set of attributes that can be added to HTML elements to improve their
accessibility and usability. The attributes are especially helpful in dynamic
and interactive elements that can’t be described by standard HTML alone.

For example, ARIA attributes can be added to semantic HTML to supplement

or override the semantic meaning of HTML elements. This is especially useful
for elements like <div> or <span> that are usually used when styling web
elements that don’t communicate their meaning. Adding an ARIA role like
‘role=button,’ ‘role=navigation,’ or ‘role=tabpanel’ can be added to better
convey the purpose of these elements to assistive technologies.

Essentially, ARIA helps to bridge the gap between HTML's semantic

capabilities and the more complex elements of web pages or applications.
When used correctly and alongside semantic HTML, ARIA attributes
contribute significantly to creating accessible web content.
A flowchart with the ARIA, HTML, accessibility, and AudioEye logos.

HTML Accessibility Best Practices

Now that you understand HTML accessibility, let’s explore best practices.
Incorporating these best practices into your development processes will help
further accessibility and usability for users with disabilities.

Use Semantic HTML Elements

As mentioned above, semantic HTML clearly conveys to users the meaning of

an HTML element. Adding the intended meaning provides more structure and
clarity to content, helping all users, not just those with disabilities, navigate
content more easily.

Provide ARIA Roles and Attributes

Along with using semantic HTML elements, use ARIA roles as well. ARIA roles,
states, and properties further accessibility for dynamic content, such as
custom widgets or interactive elements, by providing additional context for
users.

However, be sure to use ARIA responsibly

(opens in a new tab)

, only changing native semantics if you have to. For example, if a developer
wants to build a heading that’s a tab, the World Wide Web Consortium

(opens in a new tab)

 (W3C) recommends avoiding this: “<h2 role=tab>heading tab</h2> and
instead doing this: <div role=tab><h2heading tab</h2></div>.

Keep Content Simple and Clear

Avoid using overly complex layouts, excessive animations, or confusing

navigation patterns that can be difficult for users with cognitive disabilities to
understand and navigate. Use language that’s easy to understand and
conveys the meaning behind your content.

Use Proper Heading Structure

Ensure your headings are organized hierarchically (e.g., H1, H2, H3). Avoid
skipping headings levels, as this can create confusion for screen reader
users. Additionally, ensure your headings accurately describe the content
that follows.

Create Accessible Forms

Use semantic markup for forms, including <form>, <label>, <input>,

<select>, and <textarea> as you’re building forms. Ensuring each part of the
form is properly labeled helps users better understand their purpose,
enabling them to complete it more easily.

Use the lang Attribute

The lang attribute indicates the language on a page. Using it helps screen
readers and other assistive technologies correctly pronounce words,
understand and interpret abbreviations, and present content in the right
language for users. It’s a simple but effective way of ensuring content is both
accessible and inclusive to a range of users.

Include Descriptive Links

Ensure that all links (<a> elements) on your content are descriptive. They
should provide clear information about the destination or purpose of a
hyperlink before a user clicks on it. Avoid generic or vague link text like ‘click
here’ or ‘read more’ as they don’t convey meaningful information to screen
reader users or those navigating via keyboard.

Top HTML Tags to Enhance Accessibility

Using HTML tags

(opens in a new tab)

in your coding helps structure content in a meaningful, accessible manner.

By using them appropriately and combining them with the right attributes,
you can ensure web content is accessible to all users, particularly those with
disabilities.
Some examples include:

● <header>: This defines a header for different content sections,

allowing screen readers to identify content more easily and

determine its relevance.

● <nav>: The <nav> HTML tag identifies a set of navigation links and

makes them more identifiable to screen readers. Users can then

identify and skip over repetitive content and get the information

they’re looking for more quickly.

● <main>: This tag defines the main content area of a web page or

document, helping screen reader users focus on primary information

without getting lost or becoming distracted.

● <img>: The <img> increases accessibility around images or non-

text content by requiring an ‘atl’ attribute (also known as alternative

text or alt text) to be added to each one. Alt text ensures users with

visual impairments can understand the purpose and context of non-

text readers even if they can’t interact with it.

● <video> and <audio>: Both tags identify multimedia content to

users, reducing confusion. Additionally, these tags support

accessibility features like captions, subtitles, or audio descriptions,

which make multimedia content more accessible to users who are

deaf or hard of hearing.

A web browser that says Section 508, next to a laptop and an accessibility
icon

Why HTML Accessibility Matters

HTML accessibility can have a significant impact on your organization — from
both a legal and ethical standpoint.

Several accessibility laws, including Section 508 of the Rehabilitation Act

(opens in a new tab)

, the European Accessibility Act

(opens in a new tab)

(EAA), and the Accessibility for Ontarians with Disabilities Act

(opens in a new tab)

(AODA), mandate businesses to provide accessible digital services. Each of

these laws cites WCAG 2.0 as the standard to follow as they outline specific
standards and criteria for web accessibility. Criteria such as providing alt text
for images, ensuring keyboard accessibility, managing focus states, and
using ARIA roles all add to HTML accessibility. By following WCAG and
accessibility best practices, organizations ensure they follow accessibility
laws, lowering the chances of facing accessibility lawsuits or complaints.

Ethically speaking, accessible HTML code improves the user experience for all
visitors, boosting satisfaction and retention rates. It expands your potential
customer base by accommodating individuals with disabilities, representing a
huge portion of the global population. Plus, accessible websites typically rank
higher in SEO rankings, allowing more people to find your business.

Here’s the bottom line: increasing the accessibility of your HTML shows your
commitment to inclusivity and the experience of your users and mitigates
legal risk. This results in more positive business outcomes and fosters a more
inclusive digital environment for all users.

Elevate the Accessibility of Your HTML with

AudioEye
Digital accessibility starts with your HTML. The more accessible your code is,
the more inclusive an experience you can create for your users. Plus, it
ensures you’re compliant with international accessibility laws designed to
provide equal access to the digital world.

The first step to increasing accessibility is determining how accessible your

current code is—and that starts with AudioEye. Our free Website Accessibility
Checker scans your page’s code for common accessibility issues and
highlights violations.

AudioEye then goes a step further, relying on our team of human experts to
test your content for more complex accessibility errors and provide
recommendations for improvement. With these insights, you can create a
detailed remediation plan to fix accessibility errors and get closer to a more
accessible, WCAG-compliant website.

Developers can also test the accessibility of page content with AudioEye’s
Developer Tools. The online environment provides a secure place in which
developers can test inline code or individual components for accessibility
issues early in the web development process. Doing so lets you avoid
accessibility issues that could negatively impact your users.