Accessibility: What It Means and Where HTML Fits
Most of accessibility is choosing the right element. The rest is a short list of habits. Here is the framework and the small number of things that fix the majority of real problems.
- Concept
- Who this is for
- The four principles
- The things that fix the most problems
- 1. Text contrast
- 2. Missing alt text
- 3. Empty links and buttons
- 4. Missing form labels
- 5. Missing document language
- 6. Empty or skipped headings
- The first rule of ARIA
- An example, before and after
- What is not accessibility work
- Important rules
- Common mistakes
- Best practices
- Practice
-
HTML Basics
- What is HTML: The Structure Layer of Every Web Page
- HTML Document Structure: DOCTYPE, html, head and body
- Elements, Tags and Attributes: The Vocabulary of HTML
- HTML Comments: Notes That Ship With Your Code
- Block Level and Inline Elements
- Writing and Running Your First HTML Page
- How a Browser Turns Markup Into a Page
- Text and Formatting
- Links and Navigation
- Images and Media
- Lists
- Tables
-
Forms
- Form Structure: form, action and method
- Input Types: Text, Email, Number, Date and the Rest
- Labels: The Most Important Element in a Form
- Checkboxes, Radio Buttons and Grouping
- select, option, optgroup and datalist
- textarea, File Uploads and Hidden Fields
- Buttons: submit, reset and button
- Built In Form Validation
- GET or POST: What Happens When a Form Is Submitted
- Semantic HTML
- HTML5 Features
- Head and Metadata
- HTML with CSS
- HTML with JavaScript
- Accessibility
-
HTML SEO
- How Google Works: Crawling, Indexing and Ranking
- SEO Friendly HTML Structure
- Titles and Descriptions That Earn Clicks
- Headings and Content Structure for Search
- Internal Linking and Anchor Text
- robots.txt and XML Sitemaps
- Canonical URLs and Duplicate Content
- Structured Data and JSON-LD
- Image SEO
- Core Web Vitals and Mobile Friendliness
- DevTools and Debugging
- Editor Productivity
- HTML Best Practices
- HTML Projects
- Advanced Projects
- Practice and Exams
Concept
Web accessibility means building pages that work for everyone, including people who cannot see the screen, cannot use a mouse, cannot hear audio, or find dense interfaces difficult to process.
It is regularly presented as a specialist discipline requiring a separate skill set. Most of it is not. The large majority of accessibility failures found in real audits come down to a handful of markup decisions: a missing label, a missing alt attribute, a div that should have been a button, a heading level chosen for its size.
Who this is for
| Situation | What they rely on |
|---|---|
| Blind or low vision | Screen readers, magnification, high contrast modes |
| Cannot use a mouse | Keyboard, switch devices, voice control |
| Deaf or hard of hearing | Captions and transcripts |
| Cognitive differences | Clear structure, plain language, predictable behaviour |
| Colour vision differences | Information conveyed by more than colour |
| Motion sensitivity | Reduced motion preferences |
And a much larger group encounters the same barriers temporarily or situationally: a broken arm, bright sunlight, a noisy train, a slow connection, an unfamiliar language. Accessible pages are better pages for everyone, which is the honest argument, not a slogan.
The four principles
The Web Content Accessibility Guidelines organise everything under four headings, usually abbreviated POUR.
| Principle | Means | In practice |
|---|---|---|
| Perceivable | Content can be perceived by some sense | Alt text, captions, sufficient contrast |
| Operable | The interface can be used | Keyboard access, visible focus, enough time |
| Understandable | Content and behaviour make sense | Clear language, consistent navigation, helpful errors |
| Robust | It works with assistive technology | Valid, semantic markup |
Conformance comes in three levels: A, AA and AAA. AA is the practical target and is what most legislation references.
The things that fix the most problems
Annual surveys of home pages find the same failures at the top of the list year after year. Every one of them is a markup fix.
1. Text contrast
Low contrast text is consistently the most common failure found. The requirement is a ratio of 4.5 to 1 for body text and 3 to 1 for large text.
2. Missing alt text
Every img needs an alt attribute, even if it is empty.
3. Empty links and buttons
An icon only control with no accessible name is announced as link or button and nothing else.
4. Missing form labels
A field with no label is announced as edit text, blank.
5. Missing document language
One attribute: <html lang="en">.
6. Empty or skipped headings
Headings are the primary navigation tool for screen reader users.
Fixing those six things on a typical site removes most of what an audit would find.
The first rule of ARIA
If a native HTML element or attribute already provides the semantics and behaviour you need, use it instead of repurposing an element and adding ARIA.
<!-- announced correctly, and still not usable by keyboard -->
<div role="button" onclick="save()">Save</div>
<!-- everything works -->
<button type="button" onclick="save()">Save</button>ARIA changes how something is announced. It does not add behaviour. A div with role="button" is announced as a button and still cannot be focused or activated from a keyboard until you write that yourself.
This is why semantic HTML is the foundation: the elements already carry both the meaning and the behaviour.
An example, before and after
<!-- before -->
<div class="card">
<img src="/images/design.jpg">
<div class="title">Design course</div>
<div class="btn" onclick="location.href='/courses/design'">Read more</div>
</div>
<!-- after -->
<article class="card">
<img src="/images/design.jpg" alt="" width="600" height="400">
<h3><a href="/courses/design">Design course</a></h3>
<p>Three years, studio based.</p>
</article>Same appearance. The second version has a heading in the outline, a real link that can be opened in a new tab and crawled, an image that is correctly skipped as decorative, and one keyboard stop instead of none.
What is not accessibility work
- An overlay widget. Products promising one line accessibility do not fix underlying markup problems, and disability advocacy organisations have consistently advised against them.
- Adding ARIA everywhere. Incorrect ARIA is measurably worse than none.
- A separate accessible version of the site. It falls out of date within weeks.
- An audit at the end. By then the decisions are made and the fixes are expensive.
Important rules
- Native elements first, ARIA only when nothing native fits.
- ARIA changes announcements, never behaviour.
- Accessibility is decided when you choose the element, not afterwards.
- Automated tools catch roughly a third of issues. The rest needs a person.
- AA is the practical conformance target.
Common mistakes
- Treating it as a final checklist item.
- Adding ARIA to patch a poor element choice.
- Assuming a passing automated scan means an accessible page.
- Believing it only affects a small number of readers.
- Removing focus outlines because they look wrong.
- Conveying meaning by colour alone.
Best practices
- Learn the elements. Most of accessibility follows from using them correctly.
- Run through the six common failures on every page before shipping.
- Try the page with the keyboard alone once a week.
- Spend thirty minutes with a screen reader; it changes how you write markup permanently.
- Put an automated check in the build to catch regressions.
- Include accessibility in code review the way you include correctness.
Practice
- Take one of your pages and check the six common failures. How many did you find?
- Navigate a site you use daily with the keyboard alone. Where did you get stuck?
- Rewrite a
divbased card as semantic markup and list what improved. - Explain the first rule of ARIA in one sentence, with an example.