WTAG/Plan for WTAG Development
This is a planning page for developing Web Technology Accessibility Guidelines. It may leak into WAI 3.0 work.
Identify user needs that we plan to provide guidance on meeting. These should describe the needs of humans as they currently exist (i.e., without significant evolution or cyborgization from early 21st century norms), and therefore is as era-independent as possible with current knowledge. The focus is on the needs of people with disabilities, but because that is sometimes a relative / contextual condition, a significant proportion of mainstream needs will also be identified.
At least two levels of needs may be identified. The first is truly generic needs, requirements users have to access and use content such as perceive and understand it, and should be stable over time. The second layer is needs specific to technologies of the day, such as ability to understand and operate controls. This layer may be understood as an implementation of the generic needs, so may not be classed as user needs in the end. Regardless of its classification, it will be an important component of understanding the space. This level of needs evolves as technology and design patterns do, so needs to be maintainable separately from the generic needs.
Our knowledge of user needs come from a variety of sources. They should be mapped / credited to the sources to help in later communication. Sources currently under examination:
- JTC 1 User Needs
- WCAG 2.0
- UAAG 2.0
- ATAG 2.0
- Mobile, Cognitive gap analyses?
- Media Accessibility User Requirements
- Sources from other advocacy organizations
Draft User Needs collection
How to Meet User Needs
User needs need to be analyzed for how they can be met. The following ways of meeting needs are currently understood:
- Author design
- Author technical implementation
- User agent accessibility support of standard features
- User agent support of author-implemented accessibility features
- Assistive technology support (including accessibility API mediation)
These are not mutually exclusive categories. A given user need could be met by more than one of these categories, but the ability of a given category to meet a user need implies the need for guidelines targeting that category. In policy setting and evaluation there may be a preference hierarchy for how best to meet needs, e.g., user agent support of standard features is preferred, but author technical override is needed if user agent support is lacking.
Draft How to Meet User Needs analysis
Guidelines Mapping and Gap Analysis
With the above analyses done, it should be easy to see how current guidelines address which user needs. In turn it should be easy to see where current guidelines to not meet user needs, that in theory should be able to be met by activities within the remit of that set of guidelines. This should be important input into WAI 3.0 / WAI 2020 planning.
From the above analyses, it should also be easy to see where content technology features are required to make it possible to meet user needs. For example:
- If the author must implement something, the technology must provide a feature for the author to implement.
- If the user need is met by design, the technology must provide suitably rich design capabilities.
- If the user need is met by user agents, the technology must provide a sufficiently rich definition of the object for user agents to implement.
Not all technologies will address all ways of meeting user needs. For instance, CSS is primarily design-oriented, and HTML is somewhat semantics-oriented. The technology requirements may need conformance profiles or some other way of guiding technology developers seeking to follow them. It may not be easy to state in a general prescriptive way whether a given technology should, for instance, provide a richer design capability to meet a user need or should instead rely on better semantics for assistive technology-oriented content alternatives. A good structure of the technology requirements should help make it clear that some method of meeting a given user need is important. Horizontal review may continue to be important in guiding technology developers through the possibilities.
Some samples of approaches to structure of guidelines: