-
Notifications
You must be signed in to change notification settings - Fork 28
Background
Matt King edited this page Feb 12, 2023
·
1 revision
2007 time frame - To get ARIA 1.0 off the ground:
- Promise to browser vendors that supporting ARIA attributes carries no requirements to change rendering or interaction behaviors
- Promise to assistive tech developers ARIA will not specify how assistive technologies will behave
- Thus, ARIA does not include normative MUST statements for assistive technologies.
2014 - ARIA 1.0 ships:
- Major accomplishment! Difficult to overstate importance.
- However, had one big gap: shipped without authoring guidance.
- Confusion among both web authors and assistive tech devs increased over time.
- Web authors based their code on how some A/T behaved, without realizing some of that behavior was not consistent with spec.
- A/T often adjusted their code based on how some popular web sites behaved, without realizing that some ARIA usage was not consistent with spec.
- This setup a pernitious feedback loop, incorrect A/T behavior led to incorrect web author implementation, which led to more incorrect A/T behavior, etc.
ARIA has not been consistently interpreted across the industry:
- Web sites use it incorrectly.
- A/T support is not consistent or reliable.
- Browser support for some attributes is incomplete or incorrect.
Note: this does not mean all A/T need to behave identically in order for support to be reliable and consistent.
- Utility of ARIA falls far short of its realistic potential.
- Accessible web GUIs are unnecessarily complex to engineer and use.
- Sites aiming for broad audiences have to avoid certain types of GUI elements or offer alternatives.
- Eliminate confusion with clear authoring guidance, including a library of realistic examples.
- Help A/T developers leverage the library as a way of measuring and testing the quality of their support for ARIA.
100% focused on step one of strategy: Eliminate confusion with clear authoring guidance.
Approach:
- Revived interest in W3C WAI-ARIA Authoring Practices
- Built authoring practices task force.
- Adopted W3C review and conflict resolution processes.
- Establish guiding principles for ARIA pattern design.
- Deprecated/rewrote all previous draft content using these principles and processes.
- Focus on building example library; examples were external references in early drafts.
- Established consistent documentation template for examples.
- Built automated regression test system to ensure stability and reliability of all ARIA claims.
- Help assistive technology developers converge on a set of clear norms for baseline support of WAI-ARIA.
- Help web developers understand the current state of support for WAI-ARIA by assistive technologies.
Propose three workstreams:
- Project and process design
- Infrastructure development
- Assessment methodology development
- What are the deliverables and their scope?
- What are use cases for the deliverables of this project?
- How is assessment and feedback data controlled and managed?
- What processes are their for vetting data?
- How do processes ensure vendor neutrality?
- What are the processes for correcting assessment errors?
- How are disagreements resolved?
Design and build systems for:
- Compiling tests and testing instructions for each test case (ARIA design pattern example)
- Collecting assessment data
- Aggregating assessment data and calculating assessment scores
- Publishing assessments
- Gathering and responding to feedback
- For each combination of browser and A/T, define the following for each ARIA design pattern example:
- Minimal, must-have expectations
- Desirable should-have or may-have expectations
- Test conditions
- Test instructions
- Define how the assessment score will be calculated for each example?