Accessibility · built in, tested, outstanding
1. Approach
Accessibility here is a consequence of construction rather than a layer added afterwards. Pages are static HTML with semantic landmarks, headings in order, one first-level heading each, real lists, real tables with captions and one small progressive script. Nothing essential depends on JavaScript: with the script blocked, every chapter, table and checklist is fully readable.
2. What is built in
- A skip link as the first focusable element on every page, going to the main landmark.
- Semantic landmarks: a banner header, a main region, a footer, and navigation with accessible names.
- One first-level heading per page, with headings in descending order and no level skipped.
- A visible focus outline on every interactive element, using focus-visible with a three-pixel outline.
- The contents button in the header carries an aria-expanded state that changes when it is used.
- Tables carry a caption and a header row, with row headers where the first column names the row.
- Every informative image carries descriptive alternative text; the hero illustration also carries a caption.
- The entry notice is a dialog with an accessible name, a focus trap on Tab and scroll locking while open.
- Results in the story-structure meter are in a polite live region, with error text in an alert.
- The contact form groups its five labelled fields in a fieldset with a legend, and keeps native browser validation rather than replacing it.
- A reduced-motion block honours the operating-system preference for less animation.
- Text colours on the parchment ground are chosen to exceed a contrast ratio of 4.5 to 1 for body text.
- Layout is a single-column reading measure that reflows to 320 pixels and tolerates 200 per cent zoom.
3. What has been checked
Each page has been walked through with the keyboard alone, confirming that the skip link works, that focus order follows the visual order, that the contents button and the storage buttons are reachable and operable, and that the entry notice traps focus and returns it when dismissed. Headings have been read as an outline to confirm the structure makes sense without visual styling.
Forms have been checked for label association. The four fields in the story-structure meter each have a real label bound to the input, that form is set to skip native validation so that error text can be shown in a consistent place, and the error region announces changes. The five fields of the contact form each carry a real label bound to the control as well, sit inside a fieldset with a legend naming the form, and keep the browser's own validation, so a missed field is reported by the browser you already use rather than by a script of ours. Tables have been read to confirm that a caption states what the table is for rather than repeating the heading above it.
4. Known limitations
- Wide tables scroll horizontally on narrow screens. The container is focusable by scroll but a very wide table remains awkward on a small phone.
- Marginal notes move into the reading flow at narrow widths, which is correct for reading order but means they interrupt a paragraph rather than sitting beside it.
- The site has not been audited by an external specialist, so this statement records self-assessment rather than certified conformance.
- No formal testing has been carried out with every combination of browser and assistive technology; reports of specific failures are genuinely useful.
- The hand-drawn illustrations convey their information in the surrounding text as well, but a reader relying only on alternative text receives a summary rather than the full diagram.
5. Reporting a barrier
Email the desk with Access as the first word of the subject line. It helps to include the page address, what you were trying to do, the browser and assistive technology you were using, and what happened instead. The desk replies within five working days and, where a fix is straightforward, usually makes it in the same cycle.
If a page is unusable for you and you need its content, say so in the message and the desk will send the text of the chapter in a plain format. That is not a substitute for fixing the page and the fix will still be made, but it should not be necessary to wait for a fix in order to read the material.
6. Why there is no accessibility widget
Overlay widgets that promise to fix accessibility are not installed here, and will not be. They add an external request, they cannot repair underlying structure, and they frequently interfere with the assistive technology a reader already has configured. The alternative is unglamorous: correct markup, adequate contrast, real labels and a keyboard path through everything.
7. Checks you can repeat
Nothing in the list above requires specialist software, and a reader who wants to verify it can do so in a few minutes. Press the Tab key from the top of any page: the first stop should be the skip link, and every subsequent stop should be visible with an outline around it. Disable JavaScript and reload: the chapter, its tables and its checklists should be unchanged, with only the entry notice, the contents toggle and the meter absent.
Zoom to two hundred per cent and narrow the window to a phone width: the layout should become a single column with no horizontal scrolling except inside wide tables. Read the page with images turned off: every illustration should be replaced by a sentence that carries the same information. If any of those fails on your setup, that is a genuine defect and the desk would rather hear about it than not.
8. Standards referenced
The construction follows the Web Content Accessibility Guidelines at level AA as a working target, particularly the requirements on non-text content, meaningful sequence, contrast, resize, keyboard operation, focus visibility, labels, headings, error identification and status messages. Referencing the guidelines is not a claim of certified conformance, and section four above states what is known to fall short.
What to tell the desk when reporting a barrier
- The full address of the page.
- What you were trying to do at the time.
- The browser, operating system and assistive technology you were using.
- What happened instead of what you expected.
- Whether you need the chapter text sent in a plain format while the fault is fixed.