W3C/WAI produces accessibility standards as well as supplementary guidance (list) for those standards. This goal of this project is to redesign WAI's supplementary guidance, by making it easier to discover, navigate and apply in web projects.
- A designer or developer who is building a new feature, wants to learn valid ways to build their feature conform to WCAG (or UAAG, ATAG, WAI-ARIA)
- A Quality Assurance engineer who needs to approve the implementation of a new feature and wants to find a definitive source and intent
- A content strategist wants to assess whether the content in a new feature has accessibility implications
- An accessibility auditor wants to verify if something was built conform the standard
W3C/WAI's supplementary guidance is for two major groups:
- Primary: People who want the web products they work on to conform to W3C/WAI's accessibility standards (including designers, developers, content creators, quality assurance testers). Could be accessibility champions, could be team members looking for minimum conformance.
- Secondary: Educators and auditors
It is for them to learn how to get the implementation details right (i.e. not including getting the process, organisational structure and politics right).
W3C/WAI has a wealth of guidance on how to make the web accessible by applying our standards. But we could improve how it is exposed:
- findability: content is in different places, like Techniques in
/WAI/WCAG21/Techniques, Tutorials in/WAI/Tutorials, one has to know that and where they exist. One system that links out to these places could mitigate this. - recognisability: all types of guidance have different lay-outs, ideally it should be more obvious that they are part of one mission: make the web accessible (and guide people who want/have to do that). A shared header and stylesheet (at least: typography, colors and grid) can help with that.
- indication of accuracy: we have very new guidance, very old guidance, and a lot in between. Indicating accuracy or age of content should help.
- indication of ready for production: we have some technical guidance that explains how to use a technology, but leaves browser support / known browser bugs out of scope (see aria-practices/issue-353#comment-368091861, also the aria-at project). Developers may implement patterns that won't work well (now). Not our fault, clearer labeling and compatibility info could avoid potential inaccessibility (maybe complemented with “Tell AT vendor about this bug” button)
- indication of requiredness: a lot of our guidance is a way to approach a problem, not the only way. Clear
The goal of this redesign project is to:
- make guidance easy to discover (via the WAI site, QuickRef, search engines and third party sites)
- make guidance easy to understand (once found)
- make guidance easy to apply (once understood)
- includes: understand if it can/should be used today, is well-supported by assistive technologies
A visual refresh aimed at two goals:
- make guidance recognisable as WAI content, by bringing it in line with the 2019 WAI website redesign.
- structure information better, by distinguishing between the main information users look for (description, examples, tests), meta information that provides context (related SCs, related techniques/understanding)
From a technical perspective, these changes would happen in code (XSLT, CSS) that is currently responsible for guidance. For Techniques and Understanding, that is the w3c/wcag repository on GitHub.
We would not change how one gets to any of these documents. That is still as it is today: via search engines, via direct links, via the QuickRef and via the Techniques/Understanding TR pages.
- WAI simplified header (not full WAI website header)
- Note: Not including the full WAI website header helps limit technical and organisational scope. Technical: including a full header would require some mechanism to automatically import the up-to-date menu navigation links from the Ruby-based project “WAI website” into the XSLT-based project “WCAG”. Organisational: it would be hard to find a logical place in WAI website hierarchy.
- typography
- grid / layout
- colors
The goal of this is to increase recognisability and reduce cognitive load for users.
Clearly indicate:
- The type of document currently viewed
- The existence of other documents and the relation (e.g. difference between Understanding and Techniques)
Suggested improvements for Technique page:
- Make “Information about techniques” a link to one page so that we don't repeat this information on each technique or move to footer.
Mockup: related success criteria
- Create visual design for related Success Criteria, so that it is a recognisable pattern across different resources
- Move related Success Criteria and related techniques to a sidebar, visually distinguish between this type of meta information and the main technique content.
- Place content in three tabs: description, examples, tests
Rough mockup: displaying content in three tabs, moving meta data to a sidebar and visually distinguish. “What are techniques?” links to a page that explain how these apply (currently the first section).
The (tentatively named) WAI Knowledge Base would be an interface that allows people to drill down to the accessibility guidance they need, with helpful filters and metadata.
- A large part of this guidance is tied to a specific standard, but it should be discoverable both by people familiar with our standards and those who are not.
- Our guidance is produced by specific Working Groups and Task Forces; the presentation should ensure that no knowledge of that organisational structure is required to find content
- The Knowledge Base would not contain knowledge or new guidance itself, it would only link out to knowledge and guidance.
This may replace what currently lives in the Filter tab of the WCAG QuickRef tool, it can be seen as a more general W3C accessibility guidance QuickRef.
General filters:
- Tag
- Role (Developer, Designer, Content Editor, UX, Quality Assurance, etc).
Standard-based filters:
- Conformance Level (A-AAA)
- Type of WCAG Technique (Sufficient, Advisory, Failure)
For example, selecting tag ‘icons’ and ‘designer’, returns: 4 Techniques, one example from the ARIA Authoring Practices, 2 COGA notes and one applicable rule from ACT-Rules. None of these are displayed in place, they are all links to wherever these sources originally exist.
- Filters to help navigate and find the best guidance for the problem
- Holistic: it includes all of our guidance (ideally all, likely some or most; see: scope)
- Direct links to relevant resource
- Clear indication of how accurate, ready for production and required this guidance is
Mockup: knowledge base with filters left and results right
We could remove guidance that is deemed outdated. Anecdotal evidence shows this guidance is easy to find on search engines and linked from all over the web. Keeping it up leads to confusion and potentially less accessible code.
If removal is not feasible, we should add noindex instructions for search engines.
This would be a page that explains the kinds of guidance WAI offers, and the difference between them (differences in: normativity, creators, goals etc).
It would be a canonical explainer that we can link to from Technique and Understanding pages, and, in the future, other pages that have WAI guidance.
It would exist as a page on the regular WAI website, to be decided.
- Understanding
- Techniques (including "Sufficient", "Advisory", and "Failure")
Combing more difference pieces of guidance makes the “one portal” idea more useful, but also harder to execute.
- Understanding
- Techniques (including "Sufficient", "Advisory", and "Failure")
- CoGa design principles
- Low Vision practices
- ACT Rules
- ARIA Authoring Practices
- WAI Tutorials (including AV Media)
- Getting Started Tips
- Easy Checks
- Understanding
- Techniques (including "Sufficient", "Advisory", and "Failure")
Explicitly not included in this proposal are:
- improving the content of actual guidance
- Contact: Michael
- Included: Definitely
- Currently at: Understanding WCAG 2.1, Techniques for WCAG 2.1
- Understanding/Techniques look like TR pages, but they are not
- Each Technique / Understanding document is a well-formed (!) HTML page
- With Ant, the set of Technique / Understanding documents is transformed using XSLT
- There is a mechanism that takes care of links from and to success criteria, it creates cross references
- Techniques on GitHub are organised by technologies
- Understanding on GitHub is separated between 2 and 2.1
- Contact: Roy, Steve
- Included: Maybe
- Contact: Shawn
- Included: Maybe
- Contact: Shadi, Roy
- Included: Maybe
- Contact: Shadi
- Included: Maybe
- Contact: Michael
- Included: Maybe
- aria-at may result to have compat info for authoring practices