llms.txt
+32 −1
− - [Free accessibility testing tools every developer should have](https://easeweb.dev/learn/free-accessibility-tools): the free tools worth having, with what each is good for: Lighthouse, axe DevTools, WAVE, Accessibility Insights, contrast checkers, NVDA, JAWS (40 minutes at a time without a licence), VoiceOver, TalkBack, and axe-core and linting in builds.+ - [Podcasts with loud background music under the speech](https://easeweb.dev/learn/background-audio.md): Either mix the music at least 20 dB below the voice, measured on the result, or leave it out; or publish a version with no music and offer it from a button beside the player that keeps the place. Test with: audio measurement, keyboard, screen reader.+ - [Video transcripts that leave out what is shown](https://easeweb.dev/learn/descriptive-transcripts.md): Either write a descriptive transcript, with every line the video says and, where it shows them, the amounts, actions and words on screen, and put it right beside the player; or write the recipe out as the page's own text and label the video as showing those same steps. Test with: sound off, screen off, screen reader.+ - [Audio description with no gap to say what is shown](https://easeweb.dev/learn/extended-audio-description.md): Either publish an extended version, in which the picture holds on the card while its description plays, and offer it from the audio description button, or give the player the descriptions as text and have it pause the video while it reads each one aloud. The second works only where the viewer's browser has a voice for the language. Test with: screen off, keyboard, screen reader.+ - [Live radio streams with no live text](https://easeweb.dev/learn/live-audio.md): Book a live captioner (CART) for the broadcast and show their live text in a frame right beside the player. Where the host reads a prepared script and keeps to it, the script on the page is enough, but only for what is in it. Test with: sound off, screen reader.+ - [Videos without sign language, or with a tiny interpreter](https://easeweb.dev/learn/sign-language.md): Either publish an interpreted version, with the interpreter in a box beside the picture that takes about a third of the frame, and offer it from a Sign language button under the player, or show a second video of the interpreter beside the player, kept in step by a script. Either way, the interpreter is large enough to follow on a phone. Test with: sound off, keyboard, screen reader.+ - [Justified text with uneven gaps between words](https://easeweb.dev/learn/text-blocks.md): Either align the text to one edge with text-align: start, so every space between words keeps the font's own width; or keep it justified and put a switch above the text that turns justification off. Aligning to the start works for every reader, with nothing to find. Test with: text layout, keyboard.+ - [Checkout timers that release held seats](https://easeweb.dev/learn/checkout-timers.md): Take the timer out of the checkout: reserve the seats in the same request that takes the payment, and check there that they are still free. If they have gone, take no payment, keep everything typed and offer the nearest free seats. A timer people can extend still makes them finish in time, so it does not pass 2.2.3. Test with: keyboard, screen reader, zoom.+ - [Session timeouts that bring you back to an empty form](https://easeweb.dev/learn/session-expiry.md): Either send the form from the page and, when the session has ended, ask for the password in a dialog over it and send the same form again, or keep what arrives after the session has ended on the server for a day and put it back in the form once the same account signs in. Saying at the start how long the form can be left meets 2.2.6, but the form is still lost. Test with: keyboard, screen reade+ - [Striped backgrounds and op-art hero images that seem to move](https://easeweb.dev/learn/striped-backgrounds.md): Either size the stripes in percentages, so the hero holds four broad pairs at any width, or keep the fine stripes in two close tints, less than a tenth of white's luminance apart. Keeping the bold stripes to a small tile also stays under the area, up to 150% zoom. Test with: zoom, contrast measurement, flash analysis.+ - [Sign-ins you can only pass by picking pictures](https://easeweb.dev/learn/picture-sign-in.md): Take the pictures out of the sign-in. Either replace the picture step with an emailed sign-in link, or offer a passkey there with the emailed link beside it, so nobody has to recognise an object or remember which photo was theirs. Test with: screen reader, keyboard.+ - [Search boxes and related items left out of the landmark list](https://easeweb.dev/learn/region-purpose.md): Mark each area by what it is for. Either wrap the header's search form in a search element and move the related items out of main into an aside named by its heading, or, where the template's elements can't change, add role="search" to the form and role="complementary" to the related items' div, moved beside main. Test with: screen reader, keyboard.+ - [Long pages with no subheadings](https://easeweb.dev/learn/section-headings.md): Group the paragraphs by topic and start each group with an h2 that names it, such as Refunds or Exchanges, with an h3 for a topic inside one of them. The text itself stays as it is: the headings divide it, they don't replace any of it. Test with: screen reader.+ ## Words and reading+ - [Abbreviations and acronyms that are never spelled out](https://easeweb.dev/learn/abbreviations.md): Either write the expansion beside the first use of each abbreviation, as in "Active noise cancellation (ANC)", or make the letters a link to their definition on the same page or in a glossary. A title on an abbr element is not enough on its own: it shows only as a tooltip under a mouse pointer, and most screen readers don't read it. Test with: screen reader, keyboard, touch.+ - [Jargon and unusual words with no definition](https://easeweb.dev/learn/jargon.md): Either define the term in the sentence where it is used, or put a disclosure that asks the reader's question (What is the excess?) straight under it, or link the term to its entry in a glossary. All three pass; the definition in the sentence is the one every reader meets without having to ask. Test with: keyboard, touch, screen reader.+ - [Terms and policies with no plain-language summary](https://easeweb.dev/learn/reading-level.md): Either put a plain-language summary of the terms above them, before the button, and keep the full legal text below it; or rewrite the terms themselves in short sentences of common words. Both keep every charge, deadline and refund rule: the summary leaves the legal wording as it is, and the rewrite leaves one text to keep up to date. Test with: readability.+ ## Accessibility in practice+ - [What in WCAG is required, and what is only advice](https://easeweb.dev/learn/practice/how-wcag-is-built.md): Only the WCAG Recommendation is normative: its success criteria, at the level a policy picks, and its conformance requirements. Everything around them, Understanding, Techniques, the Quick Reference, ACT rules and the notes in the Recommendation itself, is informative advice.+ - [What it takes for a page to conform to WCAG](https://easeweb.dev/learn/practice/wcag-conformance.md): A page conforms when the whole page meets every success criterion of its level, or has a conforming alternate version, every page in its process does too, it relies only on accessibility-supported technology, and nothing on it blocks the rest. A claim is optional and covers only pages known to conform, so a tested sample supports a statement about a site, not a claim for every page.+ - [What EN 301 549 asks of a website beyond WCAG](https://easeweb.dev/learn/practice/en-301-549-for-websites.md): Clause 9 of EN 301 549 V3.2.1 is WCAG 2.1 Level A and AA, so a site that meets WCAG 2.1 AA meets clause 9. Table A.1, the list the EU's Web Accessibility Directive relies on, also applies clauses on video players, calls, user settings, authoring tools, documentation and support, each when its "Where…" condition holds.+ - [What a CMS or editor owes the people who write in it](https://easeweb.dev/learn/practice/authoring-tools.md): ATAG 2.0 asks two things of a tool people write web content in: Part A, that authors with disabilities can use it, and Part B, that it helps every author make content that meets WCAG 2.0, by prompting, checking, suggesting repairs and keeping accessibility information. A tool can ask for alt text and refuse a file name, but only the author knows what the image is there to show.+ - [What a screen reader gets from your HTML and ARIA](https://easeweb.dev/learn/practice/accessibility-tree.md): The browser builds an accessibility tree from the DOM: an object for each part of the page, with a role, a name, a description, states and relations, handed to the operating system's accessibility API, where the screen reader reads it. HTML fills the tree on its own; ARIA can change what goes into it, but never what the page does.+ - [Arrow keys inside a widget: roving tabindex or aria-activedescendant](https://easeweb.dev/learn/practice/keyboard-in-widgets.md): A composite widget takes one Tab stop, and the arrow keys move inside it. Either move real focus with a roving tabindex, `tabindex="0"` on the active item and `"-1"` on the rest, or keep focus on the container or input and point `aria-activedescendant` at the active item. An editable combobox needs the second, because focus has to stay in its input.+ - [Whether a technique works in the screen readers people use](https://easeweb.dev/learn/practice/accessibility-support.md): A way of using HTML, ARIA or script is accessibility supported when it has been tested to work with the assistive technology people use, in the language of the content, and in browsers they can get. WCAG doesn't say how many screen readers that takes. It requires that a page relies only on supported ways, and that anything delivered in an unsupported way is also there in a+ - [How people use the web with assistive technology](https://easeweb.dev/learn/practice/assistive-technology.md): The same page is used in very different ways. A screen reader turns it into a sequence to move through by headings, links and landmarks; a magnifier shows a small part of it at a time; speech recognition acts on the names people can see; a switch steps through it one item at a time. Each needs structure in the code, names that match what is shown, and nothing that works only with one+ - [Testing a whole site against WCAG, and standing behind the result](https://easeweb.dev/learn/practice/evaluating-a-site.md): Agree the scope, the target level and the browsers and assistive technology the site must work with; explore the site; test a structured sample and a random one; give each failure the criterion it fails; and report the date, scope, sample, method and tools, so that someone else could repeat it. The result describes the sample: conformance itself is defined page by page.+ - [What testing with disabled people finds that an audit doesn't](https://easeweb.dev/learn/practice/testing-with-users.md): An audit checks pages against WCAG's success criteria; a usability test watches disabled people try to finish real tasks, and finds what passes and still gets in their way. W3C advises doing both: testing with users can't show that a site conforms, and conformance alone doesn't show that people can use it.+ - [Who does what, and when, so accessibility isn't left to the end](https://easeweb.dev/learn/practice/accessibility-in-projects.md): Plan it: a target level in the definition of done, a named owner, a budget and training. Create it: accessible components first, so every page starts from them. Test it in every sprint, by automated checks in CI and by hand, not once before launch. Then keep checking new content and releases after launch.+ - [Which findings to fix first, and when to rebuild instead](https://easeweb.dev/learn/practice/fixing-order.md): Fix first what stops people finishing a key task, and what one change to a shared template or component clears everywhere; then what makes tasks harder; then what only annoys. When the whole interface has to change, fix the blockers now, give people another way through, and plan the rebuild.+ - [Reading a vendor's VPAT before you buy, and what to ask next](https://easeweb.dev/learn/practice/buying-accessible-software.md): A VPAT is ITI's blank template; filled in for one product, it becomes that vendor's Accessibility Conformance Report (ACR), a statement by the vendor, not a test by you. Read who tested which version, how and when, and the remarks behind each term; then test your own key tasks, and put what is still missing into the contract.+ - [Free accessibility testing tools every developer should have](https://easeweb.dev/learn/free-accessibility-tools): the free tools worth having, with what each is good for: Lighthouse, axe DevTools, WAVE, Accessibility Insights, contrast checkers, colour-vision and low-vision simulation in Chrome DevTools, the PEAT flash analyser, NVDA, JAWS (40 minutes at a time without a licence), VoiceOver, TalkBack, the accessibility tree in Chrome and Firefox DevTools and Xcode's Accessibility Inspector, + - [Accessibility checker messages, and how to fix each](https://easeweb.dev/learn/checker-messages): every message axe DevTools, Lighthouse, WAVE, miChecker, Pa11y and IBM’s Equal Access Checker show, word for word, each with the guide that fixes it.