Approach (ways we could improve)
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 sketch (for illustration only): 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
Rough sketch (for illustration only): 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 likely causes less accessible code to occur in the wild.
Examples:
- H33: Supplementing link text with the title attribute
- H45: Using longdesc
- H70: Using frame elements to group blocks of repeated material
Items we could decide to include inside EOWG/WAI-Guide scope:
- add reporting options to Techniques/Understanding pages, similar to the “Help improve this page“ boxes we have underneath WAI website pages, to provide a low barrier method for people to suggest improvements
- it links to our version control system (currently GitHub) so that people can do suggestions right in the code (with Pull Requests)
- it links to our issue management system (currently also GitHub), so that people can file issues
- it provides an email address so that people can email feedback
- add
noindexinstructions for search engines to Techniques/Understanding pages that are not latest (at the time of writing, WCAG 2.1 is latest, so the proposal would be for documents related to WCAG 2.0 to getnoindex) - design a warning
Improvements could include:
- decide which Techniques/Understanding pages could be considered outdated
- remove documents
- rewrite documents
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.