ASA’s target is to make its public digital services and core member functions conform to the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA. Accessibility is part of design, content, procurement, testing, and maintenance.
What ASA works to support
- keyboard access without a mouse;
- visible focus and logical navigation order;
- semantic headings, landmarks, lists, and tables;
- labels, instructions, status messages, and useful form errors;
- text alternatives for informative images;
- captions and transcripts for applicable audio and video;
- sufficient color contrast and information that does not depend on color alone;
- text resize, zoom, and reflow;
- controls for motion where needed;
- accessible downloads or an equivalent format;
- compatibility with current assistive technologies and major browsers within the supported environment.
Known limitations
ASA should publish a specific limitation only after testing confirms it, including the affected content, impact, alternative access, remediation owner, and target status. The public page should not list generic excuses or mark unresolved barriers as complete.
External websites, event platforms, embedded services, and historical third-party files can have different accessibility support. ASA evaluates vendors and provides an assistance route for services it uses.
Request assistance or an alternative format
Identify the page, document, event, form, or function; the barrier; the format or assistance that would help; and any relevant deadline. Do not include sensitive personal or medical information unless it is necessary and the secure method has been provided.
Report a barrier
Include:
- URL or document title;
- device and browser if known;
- assistive technology if you choose to provide it;
- the task you were trying to complete;
- what happened and any error message;
- preferred contact method.
Report an accessibility barrier
ASA should acknowledge the report, provide a route to complete time-sensitive tasks, assess the barrier, and record remediation and verification. Response targets should be published only after the support process is staffed and measured.
Accessible events
Event pages identify the accommodation route and a useful request date. ASA should not treat a later request as automatically ineligible; feasibility depends on the accommodation, timing, venue, and service provider. Event materials and recordings follow the program’s accessibility plan.
Testing and governance
Accessibility review should include automated checks, keyboard testing, screen-reader and zoom/reflow testing, form completion, document review, and user testing for material workflows. A passing automated scan alone does not establish conformance.
Procurement, design, development, content, and operations owners share responsibility. Material changes require regression testing.
Get help
Request accessibility assistance
To identify a specific issue for remediation, report an accessibility barrier.