Building accessible software is a mark of professional maturity. It shows you understand that your users have diverse needs and physical capabilities.
1The Power of Meaning
Semantic HTML isn't just about 'cleaning up' your code. It's about providing metadata that machines (like Google's crawler) and assistive devices (like Braille displays) can use to understand your application.
2Keyboard First
Can you use your entire app without a mouse? If not, it's not accessible. Mid-level developers prioritize 'Focus States' and 'Tab Order' as much as they do visual hover states.
3The ARIA Safety Net
The first rule of ARIA is: 'Don't use ARIA if you can use native HTML'. Only use it to describe complex interactions (like a custom dropdown or a modal) that don't have a native semantic equivalent.
4Step-by-Step Breakdown
Accessibility (A11y) is not a 'feature'—it's a human right. As a mid-level developer, you're responsible for ensuring your code can be navigated by anyone, regardless of ability.
Semantic HTML tells the browser 'what' the content is. Using <main>, <nav>, and <article> instead of nested <div>s provides an immediate 'map' for screen readers.
The WCAG guidelines follow the POUR principles: Perceivable, Operable, Understandable, and Robust. If your app misses one, it's not truly accessible.
ARIA (Accessible Rich Internet Applications) roles fill the gaps when standard HTML isn't enough. They are the 'bridge' for complex dynamic components.
Which of the following is a key benefit of using Semantic HTML tags like <header> and <footer>?
- →It makes the page load faster
- →It provides a clear document structure for SEO and assistive technologies
- →It automatically styles the elements with CSS
- →It prevents JavaScript errors
What does the 'O' in the WCAG 'POUR' acronym stand for?
- →Optimal
- →Ordered
- →Operable
- →Observed
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Accessible Name Computation
Every interactive element needs a computed 'accessible name'. A button with only an icon and no text, aria-label, or title has no accessible name and is announced as just 'button' by a screen reader.
<button aria-label="Close dialog"><IconX /></button>SEO Implications
- 1
Crawlability Overlap
Search engine crawlers parse the DOM in a way that closely mirrors the accessibility tree. Pages built from semantic landmarks (<main>, <nav>, <article>) and correctly nested headings tend to get better content extraction and richer snippets than div-soup pages.
Best Practices
Test With a Keyboard First
Before shipping any interactive component, unplug your mouse and try to complete the flow using only Tab, Shift+Tab, Enter, and Escape.
Automate the Floor, Not the Ceiling
Tools like axe-core or Lighthouse catch roughly a third of real accessibility issues (missing labels, contrast, alt text). They are a baseline, not proof the page is usable by assistive tech.
Frequent Bugs
A modal opens but focus stays on the page behind it, so keyboard and screen reader users keep tabbing through content they can't see.
On open, move focus into the modal and trap Tab/Shift+Tab inside it; on close, return focus to the element that triggered the modal.
Real-World Examples
Accessible Custom Dropdown
A design system's custom <select> replacement needs to behave like a native select for assistive tech while keeping its custom visual styling.
<div role="listbox" aria-expanded={open} aria-activedescendant={activeId}>
{options.map(o => (
<div role="option" id={o.id} aria-selected={o.id === activeId}>{o.label}</div>
))}
</div>