-
Notifications
You must be signed in to change notification settings - Fork 3
UI considerations
- User Experience
- About Pages
- Individual Pages
- 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
- Some understand what the different docs are, that they are not required for conformance, etc.
- Some think they understand, yet are not clear or have misunderstandings
- Some 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 on sidebar: If sidebar near top of DOM, limit amount of clutter or repetative info in it. If at end of DOM (thus end of the reading order for screen readers, small viewports, high zoom, and large text), important information that is needed up front cannot 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:
- Include not required to meet WCAG, very clear near the top.
- Include links to more info near the top.
- 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.
Users:
- Users will get to these from: ...
- Some users may walk the guidance.
- ...
...
Based on the parameters under User Experiences #ux, the following boxes are at the top of the "All" list pages. They use the design component that 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
...
On individual pages, these boxes contain the most important “meta” information about the page. Note: some documents have technical limitations due to which we can not get all important meta data, eg type of technique on technique pages.
Box lists which success criterion it relates to and how, plus any conditions.
Examples:
- when used with: “This Technique is Sufficient to meet 1.2: Time-based Media when used with G87: Providing closed captions.”
- Advisory for: “This Technique is Advisory for 3.1: Readable.“
- Sufficient for two: “This Technique is Sufficient to meet 1.1: Text Alternatives and Sufficient to meet 2.4: Navigable “
- Failure of: “This Technique is a Failure of 1.1.1: Non Text Content.”
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? (?)