Accessibility
Making software usable by everyone: audits, ARIA, contrast, keyboard and screen readers.
Download all 27
- Accessibility fix sweep for a web app
Fixes accessibility issues across a web app with a scan, keyboard and accessibility-tree checks, small fixes, a re-scan and a list for human testing. Use to clear accessibility debt in a sprint.
- Accessibility specialist
Accessibility specialist who builds and reviews with WCAG, the ARIA Authoring Practices and real assistive-technology behaviour in mind, ranking barriers by who is blocked.
- Audit game accessibility
Audits a game build or design for motor, vision, hearing and cognitive barriers using the Game Accessibility Guidelines and Xbox Accessibility Guidelines, ranked by players helped per effort.
- Audit HTML email accessibility
Audits HTML email code for screen-reader and low-vision problems specific to email clients, then returns fixed markup that still renders across Outlook, Gmail and Apple Mail.
- Audit a mobile screen for accessibility
Audits an iOS, Android, React Native or Flutter screen for labels, traits, focus order, text scaling, touch targets, contrast and gestures, with platform fixes and a VoiceOver or TalkBack test script.
- Audit motion and flashing
Audits animations, parallax, carousels and video for vestibular and seizure risk against WCAG 2.2.2, 2.3.1 and 2.3.3, then adds reduced-motion handling and pause controls.
- Audit motor accessibility
Audits a web or mobile UI for people using voice control, switch access, head pointers or one hand, covering label-in-name, target size, gestures, dragging and timing, with code fixes.
- Audit web accessibility against WCAG 2.2
Audits markup or components against WCAG 2.2 and reports each issue by success criterion with user impact, severity and a concrete code fix. Use before a release or a compliance review.
- Build an accessible media player
Builds or fixes a web video or audio player with captions, transcripts, audio description, operable controls and no autoplay traps, mapped to the WCAG 1.2 media criteria.
- Build an accessible ARIA widget
Implements a combobox, tabs, dialog, menu, disclosure, tree or listbox per the ARIA Authoring Practices pattern, using native elements whenever they suffice. Use for custom interactive widgets.
- Fix data table accessibility
Rebuilds a complex data table (grouped headers, sorting, sticky headers, row actions, responsive collapse) so screen readers announce each cell's context, with before and after markup.
- Build or fix an accessible form
Builds or repairs a web form with programmatic labels, grouping, autocomplete, helpful error messages and announced validation. Use for sign-up, checkout, settings or any data-entry form.
- Fix keyboard navigation in a component
Finds and fixes keyboard barriers in a UI component (focus order, traps, invisible focus, mouse-only controls) and adds a keyboard test checklist. Use when a widget fails without a mouse.
- Fix route changes in single-page apps
Fixes silent navigation in client-side routed apps by managing focus, page titles, live announcements and scroll on route change, plus toasts and loading states.
- Frontend accessibility rules
Standing rules that make an assistant write accessible frontend code, with semantic HTML first, labels, keyboard and focus handling, contrast, motion and ARIA only where native elements fall short.
- Make in-app charts accessible
Fixes app charts (SVG, canvas or a chart library) with a text summary, data table fallback, keyboard exploration, non-colour encodings and contrast. Code fixes, not design critique.
- Make generated PDFs accessible
Changes the code that generates invoices, statements or certificates so the PDFs come out tagged and PDF/UA-ready, with reading order, alt text, language and table headers checked in CI.
- Native mobile accessibility rules
Standing rules that make an assistant write accessible iOS, Android, React Native and Flutter UI code, with labels and traits, target sizes, text scaling, focus order and announcements.
- Preview screen reader announcements
Predicts what a screen reader would announce as you tab and arrow through markup or a component, explains why, and flags confusing announcements. For learning, not a substitute for real testing.
- Prioritise accessibility findings
Turns a long external accessibility audit into a fix plan that deduplicates by shared component, ranks by impact on key journeys, and groups work into sprints with design-system fixes first.
- Review cognitive accessibility
Reviews a built flow against the WCAG 2.2 cognitive criteria and W3C COGA patterns, covering login, time limits, redundant entry, errors and plain language, with code and copy changes.
- Review colour contrast and fix the palette
Checks colour pairs or design tokens against contrast requirements and proposes the nearest passing alternatives that keep the brand hue. Use when defining or auditing a palette or theme.
- Set up automated accessibility checks
Adds layered automated accessibility checks to a web or mobile project (editor lint, component tests, CI page scans with a baseline) and states what automation cannot catch.
- Write accessibility acceptance criteria
Turns a user story or design into testable accessibility acceptance criteria per component, mapped to WCAG success criteria, so QA and developers can check them before merge.
- Write an accessibility conformance report
Writes an accessibility conformance report (ACR) in the VPAT format from audit results, with a conformance level and specific remarks per criterion. Use when customers or procurement ask for a VPAT.
- Write alt text for images
Writes context-aware alt text for images on a page or in a document, or marks them decorative, following the W3C alt decision tree. Use when publishing images on the web.
- Write a screen-reader test plan
Writes a manual screen-reader test script for a user flow on NVDA, JAWS, VoiceOver or TalkBack, with keystrokes and expected announcements per step. Use before releasing a key flow.
Wins over code-review, testing and ui-design when accessibility is the outcome.