-
Notifications
You must be signed in to change notification settings - Fork 3
UI considerations
- User Experience
- Banner and Nav wording
- About Boxes in All Pages
- About Pages
- Individual Pages
- Sidebars
- Footers
- Archived: Summaries
Background: Requirements Analysis for WCAG supporting documents design, current user workflows
User experience issues can be broadly categorized by users' frequency-of-use and knowledge of WCAG docs:
-
Regular users
- Understand what the different docs are, that they are not required for conformance, etc.
- Think they understand, yet are not clear or have misunderstandings
- Have misunderstandings &/or are not confident in their understanding
- Landing users (e.g., gets to a page from a search engine) — Some know nothing about WCAG. Some have heard of WCAG, yet few know anything about the different docs.
Design note: The side bar is at the end of the reading order for screen readers, small viewports, high zoom, and large text. Therefore, important information that is needed up front should not be only in the sidebar.
Information note: It is very important the users know that these are informative, not normative, not required for conformance to WCAG.
UI priorities. Those user experiences and notes lead to these UI priorities:
- On all pages, put brief description with important points (e.g., not required) "front and center" for all users.
- Include links to more info.
- Make it easy for regular users to "mask out" and don't include info there that regular users need to see (because they will mask it out).
How users can get where:
- In WCAG itself, for each SC, the first link is to Understanding, the second is to How to Meet (quickref).
- In Understanding docs, Techniques are listed by sufficient, advisory, failures.
- In the QuickRef, there is a link to Understanding, and expand to show Techniques links.
- Search engines give links to Understanding and Techniques. Not usually to WCAG directly or to the quickref (unless search terms specific to those)?
Range of experiences:
- Most regular users will use the QuickRef as their primary way around, and jump in and out of the Understanding docs and the Techniques.
- Some people will occasionally dive into a single topic (from WCAG itself, from search engine, etc.) — reading the Understanding doc and several of its Techniques.
- Walking the docs (that is, going from one to the next)
- Understanding docs — rare yet happens, so supported non-intrusively ("next" at bottom of page, not top)
- Techniques — not known and thus not supported
Examples from Current user flows:
- Expert user looking for a specific technique that she remembers. Goes to QuickRef, filters, and finds link to the technique.
- QA person uses search engine, gets to Understanding, then Technique.
- Newbie searches for "color contrast rules" and gets to Understanding.
- Newbie searches for info on table accessibility and gets to a Technique.
More specific user journey example: Jan knows WCAG fairly well as Jan does accessibility audits of their organizations main websites annually. Jan has bookmarked the WCAG-EM Report Tool and the Quick Ref. When Jan is doing an audit, Jan frequently needs to check the Understanding docs and some Techniques. Common workflow:
- From the Report Tool or Quick Ref, go to an Understanding doc.
- Skim some sections and read carefully other sections.
- Go to a Technique.
- Go back to the Understanding doc.
- Go to another Technique.
- Go back to the Understanding doc.
Users:
- Target users is limited — mostly eval tool developers and test methodology developers.
- Occasionally others might look at these, e.g., when debating the finer points of conformance to a specific success criteria.
- People may land on a Rule (from search engine), when they would be better served by a Technique &/or Understanding doc.
- Most people will probably get to an individual Rule from an Understanding doc or Technique. Common user journey is similar to Jan above: From Understanding, to a Rule, back to Understanding, to another Rule, back to Understanding.
- Seldom will users walk through the Rules.
@@ list which SC &/or T4echnique it applies to ?
Users:
- Users will get to these from: ...
- Some users may walk the guidance.
- ...
...
open issues:
- "ACT Rules" vs "Test Rules for WCAG 2" or "WCAG 2 Test Rules" ? — In Techniques and Understanding, they went with "Test Rules". The Rules use the Accessibility Conformance Testing (ACT) Rules Format, and the TF and CG is called "ACT Rules". Maybe we want to leave "ACT Rules" as mostly internal terminology, and use "Test Rules for WCAG 2" or "WCAG 2 Test Rules" ?
- Is "All Rules" clear enough? Or do we need "List of All Rules"? Con: "List of All Supplemental Guidance" is really long.
- Since we have a banner, do we not need "Understanding" and "Test Rule" in the h1? For the techniques, maybe we do because we want the number in there? Or maybe just nummber not "Technique"? or maybe it's at the end of the heading?
- Instead of "Supplemental Guidance" shall the banner and nav be "Additional Guidance" or something else?
Straw proposal pending issues above:
| docs | banner | nav |
|---|---|---|
| ACT Rules | ACT Rules for WCAG 2 | All Rules | About Rules | All WCAG 2 Guidance |
| Understanding | Understanding WCAG 2.0 | All Understanding 2.0 | About Understanding | All WCAG 2 Guidance |
| Understanding WCAG 2.1 | All Understanding 2.1 | About Understanding | All WCAG 2 Guidance | |
| Understanding WCAG 2.2 Draft | All Understanding 2.2 | About Understanding | All WCAG 2 Guidance | |
| Techniques | Techniques for WCAG 2.0 | All Techniques for 2.0 | About Techniques | All WCAG 2 Guidance |
| Techniques for WCAG 2.1 |
All Techniques for 2.1 | About Techniques | All WCAG 2 Guidance | |
| Techniques for WCAG 2.2 Draft | All Techniques for 2.2 | About Techniques | All WCAG 2 Guidance | |
| COGA +others | Supplemental Guidance to WCAG 2 | All Supplemental Guidance | About Supplemental Guidance | All WCAG 2 Guidance |
Based on the parameters under User Experiences #ux, the following boxes are at the top of the "All" list pages and each individual page. They use the design component taht is used for summaries on WAI pages.
About Techniques
WCAG Techniques provide specific guidance on how to create accessible web content. They are primarily for developers, designers, and testers. Most techniques apply to a specific WCAG success criteria and technology (such as CSS).
Techniques are not required to meet the WCAG standard. They are "informative", and not part of the WCAG standard. To learn more, see: Web Content Accessibility Guidesline (WCAG) Overview, All WCAG 2 Guidance, About Techniques.
About the Understanding WCAG Docuemnts
The Understanding WCAG documents are for people who want to understand the guidelines and success criteria more thoroughly. They are "informative", and not part of the WCAG standard. To learn more, see: Web Content Accessibility Guidesline (WCAG) Overview, All WCAG 2 Guidance, About Understanding WCAG.
About the [ ACT Rules for WCAG 2 | WCAG Test Rules]
[ ACT Rules for WCAG 2 | WCAG Test Rules] describe ways to test conformance to WCAG success criteria. They are "informative", and not part of the WCAG standard. They are primarily for developers of evaluation tools and test methodologies.
Others may find more relevant guidance in Understand WCAG and WCAG Techniques. To learn more, see: Web Content Accessibility Guidesline (WCAG) Overview, All WCAG 2 Guidance, About [ ACT Rules for WCAG 2 | WCAG Test Rules].
About Supplemental Guidance to WCAG 2
Supplemental Guidance goes beyond the requirements of the WCAG standard. It is not required for conformance to WCAG. However, following this guidance will increase accessibility for people with cognitive and learning disabilities, and people with low vision. To learn more, see: About Supplemental Guidance.
ARIA APG
...
- In summary or first paragraph, link to higher level All WCAG 2 Guidance
- ...
- Include Page Content box, like on WAI pages.
Design note: The side bar is at the end of the reading order for screen readers, small viewports, high zoom, and large text. Therefore, important information that is needed up front should not be only in the sidebar.
@@ content for each to-be-defined
Date: This Rule was updated 00 Month 2021. First published Month 2021.
Authors: Name One, Name Two, Name Three, Name Four, Name Five. Contributors: Name Six and ACT Rules CG participants.
This Rule was developed by the ACT Rules Community Group (CG) as part of the WAI-Tools project, co-funded by the European Commission. The user interface was developed by Wilco Fiers and Hidde de Vries as part of the WAI-CooP project, co-funded by the European Commission.
Date: Updated 00 Month 2021. First published Month 2021.
Developed by Accessibility Guidelines Working Group (AG WG) Participants (Co-Chairs: Alastair Campbell, Charles Adams, Rachael Bradley Montgomery. W3C Staff Contact: Michael Cooper).
The content was developed as part of the WAI-Core projects funded by U.S. Federal funds. The user interface was developed by Hidde de Vries with contributions from Shadi Abou-Zahra and Shawn Lawton Henry, as part of the WAI-Guide project, co-funded by the European Commission.
......
below is incomplete draft
@@Date: @@ Information on specific evaluation tools is updated frequently, as we receive it. In the "Detailed Information" for each tool, there is an "Information updated:" date. This user interface was updated in March 2016. The list was first published in March 2006.
Editors: @@name, @@name. Contributors: @@name, @@name, and participants of the @@WG.
Developed by the @@ Working Group (@@WG). Developed as part of the WAI-@@ project, @@co-funded by the European Commission.
@@Date: Updated @@ Month 2021. First published Month 20@@. Changelog.
Editors: @@name, @@name. Contributors: @@name, @@name, and participants of the @@WG. Acknowledgements lists contributors and credits.
Developed by the @@ Working Group (@@WG). Developed as part of the WAI-@@ project, @@co-funded by the European Commission.
straw proposal:
Summaries are short, high-level descriptions of a page or set of pages.
User questions to answer:
- What is this set of documents?
- Where do I find out more about this type of document?
- Where do I find out more about all types of documents?
User questions to answer:
- What type of document am I looking at?
- How does it relate to WCAG?
- Is it required? (?)