Lets talk about A11y

Accessibility, popularly known as a11y and luckily pronounced [ˈæ.li] was the topic of many of the talks I attended lately. My main takeaway was that accessibility is about solving real problems for real people — not just compliance and checklists.

The rest of the post are my notes, packed with insights for me but also other developers, designers, and product teams.

Principles for building accessible products

  • It is much cheaper to end up with a truly accessible product when a11y is built-in from the start
  • Making a product accessible after it’s built is a recipe for disaster as it leads to expensive fixes and often it will still be frustrating to use for people who need a11y features.
  • Keyboard-first thinking: Do not focus on ARIA labels for screen readers. Put your thinking instead on making your product awesome for the power users that will benefit from a keyboard friendly UI. Then you will have a good chunk of the work before even polishing those ARIA labels.
  • To help you develop the keyboard-first UI add temporally this rule
    It will make very clear what element is currently in focus
    *:focus { outline: 5px solid #FF00FF !important; }
  • If you need to champion A11Y internally and your management resist it, play the joker card of law enforcement to at least start steering the ship. Fines for non-compliance will be expensive and completely preventable.

ARIA critical rules

  • Don’t use ARIA labels, use native HTML instead
Do not use
<div role=button>Title</div>
Instead use
<button>Title</button>
  • Use semantic elements and do not change their semantic meaning

That means you need to get used to section, article, and panel because screen readers depend on structure.

You should not do
<h2 role=tab>Title</h2>
Instead use
<div role=tab><h2>Title</h2></div>
  • Interactive ARIA controls must be focusable and they must have a name

Make sure you don’t hide buttons for keyboard users or use role=”presentation” / aria-hidden=”true” on a focusable element. If you add those labels the element will disappear from the a11y tree and it will be invisible for screen readers.

  • Make sure that input fields and their labels are correctly linked
  • The page needs to start with an element with role=banner (header)
  • The page should have 1 element with role=main
  • Elements with the role=generic have no names and are unfocusable
  • Input fields that cannot be changed should have readonly=”true” (Do not use disabled)

Screen readers

  • The most dominant software products are NVDA (Free, open source) and JAWS (Awfully expensive, legacy tool still used for compliance audits but quickly losing traction). Other software (Voice over in mac, Orca in Linux) is irrelevant.
  • Your users may also use Braille Displays to input text. They look like this This is actually an hibrid device, it can display braille (with two extra dots per letter to mark text style) to read the text and has a chorded keyboard for input. The buttons on top of the braille are used to accurately select and manipulate text.

    Why do modern screen readers still sound like Stephen Hawking’s synth voice?
    “While natural sounding voices exist, blind people prefer the old classic robotic synth better because it is still intelligible when you crank the speed up. The natural sounding synths cannot handle this abuse.”

  • There are laws in Europe that cover usability (European Accessibility Act, EN 301 549 / WCAG2.1). Enforcement began last month (2025.06).
  • Around 10% of the companies did some effort to be compliant. That does not mean they are actually compliant.
  • It does not affect internal B2B products (not in customer facing roles) nor business under 2 million EUR revenue. It does not apply to non commercial websites like personal blogs.

Tools (For websites)

  • Use tools to help you find mistakes on the accessibility tree, but do not think everything is perfect if the tool does not flag issues.
  • Tools can not tell if a workflow makes sense for blind users.

    “Tools catch ~50% of issues—the rest need humans.”

  • Navigate your app using only a keyboard. Check if you can reach every button.

    “Meeting WCAG AA doesn’t mean your UI is efficient for blind users.”

  • Recommendation: Integrate axe on the pipelines, do check on Lighthouse while doing a new feature. Use IBM Equal Access for pre-launch deep dives.
Tool Type Best For Strengths Weaknesses URL
axe Browser Extension Developers CI/CD integration, code-level fixes Misses UX issues https://github.com/dequelabs/axe-core
WAVE (WebAIM) Browser Extension Designers/QA Visual error overlay Less actionable for devs https://wave.webaim.org/
WCAG Contrast Checker Browser Extension Designers/QA Colors — https://www.tpgi.com/color-contrast-checker/
Lighthouse Built-in Browser Tool Quick audits of the A11y tree Built into Chrome Surface-level only https://developer.chrome.com/docs/lighthouse/
IBM Equal Access Browser Extension More advanced audits Custom rulesets, detailed reporting Kills my browser https://www.ibm.com/able/toolkit/
PDFs: PAC Document checks WCAG validation for PDFs Windows-only

Component libraries

Internal Reporting

  • A Voluntary Product Accessibility Template (VPAT) is an internal document detailing your product’s a11y status. It lists tools used, OS versions, and failures/ workarounds. Never make this public it’s a roadmap for fixes, not a PR stunt.
  • Use VPATs to prioritize fixes (For example “JAWS issues = critical”).

External Reporting

  • Do not put accessibility information under the Terms and Conditions(AGB). If you update your AGB, you must notify all users which is a nightmare for minor fixes.
  • Solution: Create a standalone page for info. In German this is the “Erklärung zur Barrierefreiheit” (EzB)
  • A good example: Check 1&1 Ezb. Notice also they declare compliance but openly disclose quite a few known violations.