Friday
\n12 June, 8 pm
\nSAR 180
\nOpen Ticketly with your screen turned off. That sounds like a stunt, but it is what Samir does every working day, and it is the fastest way to understand what your code really sends to the people using it. Before you fix anything, you need a clear picture of how assistive technology (AT) gets information out of a web page.
\nAssistive technologies don’t look at your pixels. The browser takes the DOM, combines it with CSS, and builds a second, simpler tree: the accessibility tree. Each node in it has a few properties:
\nThe browser hands that tree to the operating system’s accessibility API, and the screen reader, magnifier or voice control software reads it from there.
\nHere is part of Ticketly’s event card, and what the tree contains for it:
\n<h3>Harbour Lights: Friday</h3>\n<div class=\"btn\" onclick=\"book('fri')\">Book now</div>\n<button type=\"button\" onclick=\"book('sat')\">Book now</button>heading "Harbour Lights: Friday" (level 3)\ngeneric\n text "Book now"\nbutton "Book now"The div shows the same text, but its role is generic. A screen reader reads “Book now” as a sentence, with no hint that it does anything, and it can’t be reached with the Tab key. You can inspect this yourself: in Chrome or Edge DevTools, select an element and open the Accessibility pane; Firefox has a dedicated Accessibility Inspector tab.
\nScreen readers (NVDA and JAWS on Windows, VoiceOver on Apple devices, TalkBack on Android) turn the tree into speech or braille. Users rarely listen to a page top to bottom. In WebAIM’s 2026 survey, 67.8% of screen reader users said their first move on a long page is to jump between headings. They also pull up lists of links, landmarks and form fields. Your structure is their table of contents.
\nScreen magnifiers (Windows Magnifier, macOS Zoom, ZoomText) enlarge a small region that follows the focus or pointer. Maha, a designer on my team, works at 400%: she sees about a sixteenth of the screen at once. Anything that happens far from her focus, like a toast in the opposite corner, didn’t happen as far as she is concerned.
\nSwitch access users press one or two physical switches. The software steps through focusable elements, and a switch press activates the current one. If an element isn’t focusable, it can’t be reached at all. Switch users depend on the same keyboard operability you will build in Section 3.
\nVoice control (Voice Control on macOS and iOS, Dragon on Windows) lets people say “click Book now” or “show numbers”. The software matches spoken words against accessible names. When a button reads “Book seats” on screen but has aria-label="cta-primary", the words Dina says don’t match the name and nothing happens. WCAG calls this Label in Name: the accessible name must contain the visible text.
Two patterns cover most cases on Ticketly.
\nWhen a visual cue carries meaning that has no text, add text that only the tree sees. Ticketly marks a sold-out date with a strike-through and grey colour. A screen reader announces “SAR 180” and Samir happily tries to buy it. Add a visually-hidden note:
\n.visually-hidden {\n position: absolute;\n width: 1px;\n height: 1px;\n margin: -1px;\n padding: 0;\n overflow: hidden;\n clip-path: inset(50%);\n white-space: nowrap;\n border: 0;\n}<p class=\"price sold\">SAR 180 <span class=\"visually-hidden\">(sold out)</span></p>When an element is decorative, hide it from the tree. Ticketly puts a small calendar icon before every date. Inline SVGs can be announced as “image” or “graphic”, which is noise. aria-hidden="true" removes them:
<p class=\"date\"><svg class=\"icon\" aria-hidden=\"true\" viewBox=\"0 0 16 16\">…</svg> 12 June, 8 pm</p>The tree is the contract between your code and every AT. Next you will see the standard that defines what that contract must include: WCAG 2.2.
\n","toc":[{"id":"sec-1","text":"The accessibility tree","level":2},{"id":"sec-2","text":"Four ways people operate Ticketly","level":2},{"id":"sec-3","text":"Showing it to the tree, not the eye","level":2}],"takeaways":["Assistive technologies don’t read your pixels; they read the accessibility tree, where each node has a role, a name, and states or a value.","Screen reader users move by headings, landmarks, links and form fields, so structure is their table of contents.","Magnifier, switch and voice control users depend on visible focus, keyboard operability and visible labels that match accessible names.","display none, the hidden attribute and aria-hidden remove content from the tree; a visually-hidden class hides it from the eye but keeps it for screen readers."],"further":[{"title":"MDN: Accessibility tree","url":"https://developer.mozilla.org/en-US/docs/Glossary/Accessibility_tree"},{"title":"W3C WAI: Tools and Techniques used by people with disabilities","url":"https://www.w3.org/WAI/people-use-web/tools-techniques/"},{"title":"MDN: aria-hidden","url":"https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-hidden"}],"quiz":[{"q":"A screen reader user reaches this element. What does the accessibility tree give the screen reader to announce?
\n<div class=\"btn\" onclick=\"book()\">Book now</div>Maha uses screen magnification at 400%, so she sees about a sixteenth of the page at a time. Ticketly shows “Added to basket” in a toast at the top-right corner while she is clicking a button bottom-left. What is the main barrier?
","options":[{"text":"The toast has no ARIA role","why":"A role helps screen reader users, but Maha reads with her eyes. A perfectly marked-up toast is still invisible to her if it appears far outside her viewport."},{"text":"The toast text is too short","why":"Length is not the issue here. The message appears in a part of the screen she is not looking at."},{"text":"The message appears far away from where her attention and focus are","why":"Correct. Magnifier users see a small window around the focus or pointer, so feedback should appear near the control that caused it."}],"answer":2},{"q":"Dina controls her computer by voice. The button shows the text “Book seats” but has aria-label="cta-primary". What happens when she says “click Book seats”?
Which CSS hides a “Sold out” note from sighted users but keeps it in the accessibility tree?
","options":[{"text":"display: none","why":"display none removes the element from the accessibility tree as well as from the screen, so screen readers never hear it."},{"text":"visibility: hidden","why":"visibility hidden also removes the content from the accessibility tree."},{"text":"opacity: 0 on the parent card","why":"That hides the whole card from sighted users, which is the opposite of what you want, and it doesn’t help screen reader users either."},{"text":"A visually-hidden class that clips the element to a 1px box with position: absolute","why":"Correct. The element still renders, so it stays in the tree, but it takes no visible space."}],"answer":3}],"exercise":{"kind":"web","mode":"dom","starter":{"html":"12 June, 8 pm
\nSAR 180
\n13 June, 8 pm
\nSAR 180
\n12 June, 8 pm
\nSAR 180 (sold out)
\n13 June, 8 pm
\nSAR 180
\nTicketly’s Friday price (#fri-price) is struck through and greyed out because the date is sold out, but a screen reader only hears “SAR 180”. Meanwhile every decorative SVG icon can be announced as an unlabeled graphic.
#fri-price so they reach the accessibility tree. You can show them, or hide them visually with a .visually-hidden class (not display: none).<svg> icons from assistive technology.#sat-price) available.