Introduction to Accessibility (a11y)

Welcome to the start of the accessibility section. Before any code, one question: what is accessibility, in plain words?

It is making sure that people can actually use what you build. Not "people who see well, hear well, hold a mouse steadily, and read your language at your speed." Just people. Accessibility is the quality of being usable by the widest range of people in the widest range of situations.

You will often see it written a11y. That is a numeronym: the letter a, then 11 letters, then y (a-c-c-e-s-s-i-b-i-l-it, 11 letters, then y). It saves typing, and is easy to search for.

What You Will Learn

• What accessibility means, and why it matters
• The myths that stop people from starting
• How assistive technology sees your page: the accessibility tree
• Why a real button beats a fake one
• How to run a ten-minute audit on any page
• The right mindset: build it in, not bolt it on

The Big Idea

HTML Code

index.html

<!-- A fake button: looks right, but is not a button -->
<div class="btn" onclick="subscribe()">Subscribe</div>

<!-- A real button: reachable, pressable, and announced correctly -->
<button type="button" onclick="subscribe()">Subscribe</button>

Keyboard Test

http://127.0.0.1:5500/index.html

Try to fix the fake button, one step at a time

Add tabindex="0" to the fake button Add Enter and Space handling to the fake button

Press Tab to move around, then Enter or Space to press. You can use the mouse too.

Fake button (a span)

What each one really did

Test	Fake button	Real button
Reached with Tab	No	No
Pressed with the mouse	0 time(s)	0 time(s)
Pressed with the keyboard	0 time(s)	0 time(s)

The fake button cannot be reached with Tab at all, so a keyboard user cannot even find it.

Both elements are real, and the counts come from real browser events. The real button needed no extra code. Whether the keyboard press counts as a click is decided by the browser, not by this demo.

Both look the same. But try pressing Tab. One of them is invisible to a keyboard. That single difference is the heart of accessibility: what the page looks like is not the same as what it is.

Why Accessibility Matters

1. It is about people

Roughly one in six people in the world lives with a significant disability, according to the World Health Organization. Add people who are temporarily injured, tired, in bright sunlight, using a slow phone, or reading in a second language, and the group becomes almost everyone, at some time. A page that does not work for them is a page that does not work.

2. It is often the law

Many countries have laws or policies that require accessible websites, especially for public services, shops, banks, education, and employers. Examples include the Americans with Disabilities Act and Section 508 in the United States, the European Accessibility Act and the EN 301 549 standard in the European Union, and equivalents in many other places. They usually point to the Web Content Accessibility Guidelines (WCAG). The details differ, and change over time, so check the rules for your own situation. This is not legal advice.

3. It is good for business

Accessible sites reach more customers, convert more visitors, and are cheaper to maintain, because clean, semantic code is easier to change. Many accessibility improvements overlap with search engine optimisation, mobile friendliness, and better overall usability.

4. It is a sign of quality

An accessible page is usually a well-built page: clear structure, honest HTML, readable text, predictable behaviour. Developers who build accessibly tend to build better in general.

Myths and Realities

Myth	Reality
"Accessibility is only for blind people."	It covers seeing, hearing, movement, thinking, and learning, plus temporary and situational limits
"Nobody who is disabled uses my site."	You cannot know. Many people do not announce a disability, and inaccessible sites push users away before they ever tell you
"It is expensive and slow."	Building it in from the start costs little. Fixing it later is what costs a lot
"It makes sites ugly."	Accessible sites can be beautiful. Good contrast, clear layout, and readable type are also good design
"An automatic tool can check everything."	Tools find only a portion of problems. They cannot judge whether your alt text is good, or whether the page makes sense
"ARIA fixes any problem."	ARIA adds information. It does not add behaviour. The best fix is usually native HTML
"I will do it after launch."	After launch, it is harder, costlier, and often forgotten
"Text-only versions solve it."	Separate versions are usually out of date, and treat people unequally. Make the main site accessible

The Key Idea: The Accessibility Tree

When a browser reads your HTML, it builds the DOM, the tree of elements. It then builds a second, smaller tree for assistive technology: the accessibility tree. For each important element, it records four things:

Piece	Question it answers	Example
Role	What is it?	button, link, heading, checkbox
Name	What is it called?	"Subscribe", "Email address"
State	What is its condition?	checked, expanded, disabled, pressed
Value	What does it contain?	the text in a field, the position of a slider

A screen reader does not look at your pixels. It reads this tree. When a native HTML element is used, the browser fills in the role, name, and state for you. When you build a fake control from a div, the tree shows only "generic", and you must add everything yourself.

Try the viewer below. It is a simplified version of the real thing. Start with the faulty sample, and find the problems. Then load the good sample and compare.

HTML Code

tree-example.html

<!-- The tree sees: button "Subscribe" -->
<button type="submit">Subscribe</button>

<!-- The tree sees: textbox "Email address" -->
<label for="email">Email address</label>
<input id="email" type="email">

<!-- The tree sees: img "A golden sourdough loaf" -->
<img src="loaf.jpg" alt="A golden sourdough loaf">

<!-- The tree skips it: decoration -->
<img src="swirl.svg" alt="">

Tree Viewer

http://127.0.0.1:5500/index.html

You can see the real accessibility tree in your own browser: open developer tools, and look for an Accessibility panel, in the Elements area in most browsers.

The Good News

You do not have to memorise hundreds of rules to start. A small number of habits fix most real-world problems:

1. Use the right element for the job.
2. Give every control a name.
3. Keep a logical heading structure.
4. Describe meaningful images.
5. Make everything work with a keyboard, with a visible focus.
6. Use enough contrast, and never rely on colour alone.
7. Say what went wrong, in words, when something fails.

The rest of this section teaches each of these in depth.

Your First Ten-Minute Audit

Open any page you have built (or a favourite site), and work through these checks. You need no special tools. Tick each one as you go.

HTML Code

audit-notes.txt

Page: Home
Date: ____

Keyboard:   reached everything? ____   focus visible? ____
Zoom 200%:  anything broken?    ____
Headings:   logical outline?    ____
Images:     alt text OK?       ____
Forms:      every label OK?    ____
First fix: ____________________

Quick Audit

http://127.0.0.1:5500/index.html

1. Put the mouse aside. Press Tab repeatedly. Can you reach every link, button, and field?
2. Is the focus always visible? Can you tell where you are?
3. Zoom the page to 200 percent. Does anything overlap, disappear, or need sideways scrolling?
4. Look at the headings only. Do they tell the story of the page in order?
5. Is every image either described, or deliberately left empty because it is decoration?
6. Does every form field have a visible label that stays on screen?
7. Read each link out of context. Would 'Read more' or 'Click here' make sense in a list of links?
8. Is anything explained only by colour? Squint, or use a grayscale filter, to check.
9. Does the page have a language set and a clear, unique title?
10. Run one automatic checker, and then fix the first problem it finds.

0 of 10 steps done (0 percent). Open any page you have built, and work through the steps.

The Right Mindset

• Build it in from the start. Accessibility added at the end is slow and fragile. Accessibility designed in at the beginning is nearly free.
• Start with semantic HTML. It gives you roles, names, keyboard support, and states with no extra work.
• Use progressive enhancement. Make the core content and actions work with plain HTML. Then add styling and scripting on top.
• Test early and often, with a keyboard, with zoom, and with a screen reader.
• Listen to disabled people. Their experience is the real test, and the best teacher.
• Aim for progress, not perfection. No site is perfect. Fix the biggest barriers first, and keep improving.
• Share responsibility. Designers, writers, developers, testers, and managers all affect accessibility.

Inclusive Design: A Wider View

Accessibility is usually about removing barriers, so that disabled people can use a product. Inclusive design goes a step further: it asks who might be left out, and designs for that range from the start. A helpful idea comes from the Microsoft inclusive design approach: a permanent, temporary, or situational limit can look the same. One arm cannot hold a phone, whether it is broken, whether you were born that way, or whether you are carrying a baby. Designing for one helps all three.

Good Habits

1. Use semantic HTML first.
2. Use real buttons and links.
3. Label every control.
4. Check with the keyboard before you share any page.
5. Zoom to 200 percent as part of every review.
6. Write clear, plain content.
7. Test with at least one automatic tool and one manual method.
8. Keep learning. Accessibility is a skill that grows with practice.

Accessibility Checklist

• The page uses real headings, landmarks, lists, buttons, links, and form controls.
• Every control and meaningful image has a name.
• Everything can be done with a keyboard, with a visible focus.
• Text has enough contrast, and meaning is never shown by colour alone.
• The page works at 200 percent zoom.
• Media has captions and transcripts.
• Errors and updates are described in words, and announced.
• The page has a lang and a unique <title>.
• You have tried at least one screen reader.

Security and Privacy Notes

• Treat disability information as sensitive. Do not require people to disclose it, and do not store it without a clear purpose and consent.
• Do not profile people through their assistive technology. Detecting screen readers or accessibility settings to track visitors is intrusive. Respond to their preferences with CSS (such as prefers-reduced-motion) and do not log them.
• Make security features accessible too. Login steps, CAPTCHAs, and timeouts that exclude people create both a barrier and a risk, because people then look for unsafe workarounds. Offer secure, accessible alternatives, such as passkeys or one-time codes with enough time.
• Do not put private details in text that is read aloud, such as a full card number in an error message, because other people can hear it.
• Accessibility overlays and plug-ins that promise instant fixes often add scripts from third parties and still miss real problems. Be careful with them, and review what they load.

Global Audience Notes

• Accessibility needs differ across the world. Many people use older phones, shared devices, slow networks, and free or built-in assistive tools. Lean, semantic HTML serves them best.
• Language matters. Set lang, mark passages in other languages, and write plain text that translates well. Screen readers use lang to choose a voice.
• Right-to-left languages need dir="rtl", and testing with real assistive technology.
• Standards and laws vary, but WCAG is used or referenced in many countries, which makes it a good common target.
• Different scripts need different text handling, such as larger sizes for some writing systems. Test with real content in each language you support.
• Avoid assumptions about names, dates, addresses, and abilities. Give people flexible ways to enter and read information.

Common Mistakes to Avoid

1. Treating accessibility as a checklist for the last week.
2. Making a fake button from a div.
3. Hiding the focus outline.
4. Using placeholder text as the only label.
5. Skipping alt text, or writing "image of …".
6. Using colour alone to show meaning.
7. Trusting an automatic tool as proof of accessibility.
8. Adding ARIA without understanding it.
9. Never trying a keyboard or a screen reader.
10. Assuming your own way of using the web is the only one.
11. Building a separate "accessible version".
12. Giving up because nothing is perfect.

Practice Time

Try these in your browser and your editor:

1. Do the ten-minute audit above on a page you built.
2. Use the keyboard test above, and explain in one sentence why the fake button fails.
3. Use the tree viewer to find all the problems in the faulty sample, and fix them one by one.
4. Open your browser's Accessibility panel on a real page, and find a heading, a link, and a button.
5. Replace one div onclick on your own site with a real button.
6. Turn on a screen reader (such as the one built into your phone) for five minutes, and use a site you know.
7. Write a one-paragraph summary of why accessibility matters, for a friend who is a business owner.
8. List five situations when you have been temporarily limited (for example, bright light, noise, one hand free).
9. Choose one myth from the table above, and write a short reply to it.
10. Bonus: write a one-page accessibility promise for your next project, listing the habits you will keep.

Quick Recap

Click a question to check your answer.

1. What does a11y mean?

It is short for "accessibility": the letter a, then 11 letters, then y.

2. Who benefits from accessibility?

People with permanent disabilities, people with temporary limits (such as a broken arm), people in difficult situations (such as bright sunlight or a noisy room), and often everyone else too.

3. What is the accessibility tree?

A tree the browser builds from your HTML for assistive technology. For each important element, it records a role, a name, a state, and a value.

4. Why is a real button better than a div that looks like a button?

A real button is reachable with Tab, works with Enter and Space, and is announced as a button, all without extra code. A div has none of that unless you build every part yourself.

5. Can an automatic tool tell you if your site is accessible?

No. Tools find only some problems. You also need manual checks, such as keyboard and screen reader testing, and ideally feedback from disabled users.

6. When should you start thinking about accessibility?

At the very beginning of a project. Building it in from the start is far cheaper and more reliable than fixing it later.

Key Takeaways

• Accessibility (a11y) means making things usable by the widest range of people, in the widest range of situations.
• It matters for people, the law, business, and quality.
• Browsers build an accessibility tree of roles, names, states, and values from your HTML. Native elements fill it in for you.
• A fake control from a div fails the keyboard, and tells assistive technology nothing.
• Start with a few habits: the right element, a name for everything, logical headings, described images, keyboard support, good contrast, and clear errors.
• Build it in early, test with real methods, and listen to real people.
• Be careful with the privacy of disability information, and with shortcuts that promise instant accessibility.

Next, learn the standard that most of the world follows: WCAG Basics.