Accessibility

Accessibility brings together focused browser tools for people who need to help teams find and plan practical accessibility improvements in documents, images and digital publishing. Checklists and decision trees make issues easier to notice, but accessibility is experienced by people using the finished content, not established by completing a form alone. Start with the specific outcome you need, then choose a workspace that can produce something you can review and use. A clear question is more useful than a broad promise: decide what must be calculated, organized, converted, checked or prepared.

Start with the user's task and the format they need to access. For an image, decide whether it communicates information or is decorative, then draft alt text that conveys the relevant purpose without repeating nearby text. For a PDF, inspect reading order, headings, tables, text selection and keyboard use. Prioritize fixes that block access and confirm each change in the actual output. For recurring work, keep the assumptions and review date with the result. If the task changes, update the inputs before reusing an earlier answer.

Before starting, gather the document or page, its audience, reading order, image purpose, language and applicable accessibility standard. Keep the source file so remediation can be repeated after edits. If you use an automated checker, record its findings but also inspect content that requires human judgment, such as meaningful link text or whether an image's alternative is useful in context. Examples currently listed here include PDF Accessibility Checklist, Accessible PDF Remediation Plan, Image Alt Text Decision Tree and Accessible Presentation Checklist. Choose by the job and the tool's stated inputs and output, not by a similar-sounding name. Keep the original material so you can check what changed.

Related language includes “PDF Accessibility Checklist” and “accessibility checker.” Use those phrases to clarify the task, then check that the selected tool matches the details of your case. The wording is a way into the problem, not a substitute for checking fit. A broad phrase can describe different tasks, so use the individual workspace instructions to confirm what it accepts and produces.

Check the output's units, dates, labels and source values before using it. A PDF accessibility checklist should guide a review of structure and navigation, while a remediation plan should give each issue an owner and a retest step. Test with keyboard interaction and, where possible, assistive technology. Ask people with relevant lived experience to review critical journeys rather than treating automated success as proof that all users can complete them. Open files in the destination application; for a calculation, test a known example and keep enough working to explain the result.

Use these workspaces as practical aids, not automatic approval for a consequential decision. Accessibility requirements depend on the service, jurisdiction and applicable standard. Automated tools cannot identify every barrier, and a completed checklist does not certify conformance. Avoid publishing personal information in examples, and provide a clear contact route when someone needs an alternative format or help. Check the specific tool's current data-handling details before sharing personal or confidential material, and have the responsible reviewer confirm outputs used for submissions, payments or decisions about other people.