Summaries for SCs - tweak "In brief" and persona quotes

[shawna-slh]

Latest drafts:

• example of In brief DL at top of an Understanding doc,
  example of In brief bullets at top of an Understanding doc (img)
• What's New in 2.2 — preview, PR196, file to edit
• all in brief text (Google doc)
  • 2.2 SC in briefs PR
  • 2.1 SC in briefs PR
  • 2.0 SC in briefs PR

---

Background:

• EOWG contributed to persona quotes that we used to introduce the new SCs in What's New in WCAG (2.1 and 2.2).
• AG wrote "in brief"s to go in the Understanding docs, e.g., Understanding Dragging
• EOWG discussed using these as input into a simple summary for both the What's New docs and the Understanding docs. 16 May minutes

Initial ideas include:

• Make this a simple language summary
• Put it before the SC wording, that is, at the top of Understanding docs (already that way in What’s New)
• Consider not putting the whole persona quotes, yet do include a persona scenario, not just disability group

Rationale for putting info at the top:

• Demystify before presenting the SC wording, some of which is very complex (even though the point is simple).
• WAI and the broader accessibility community want to focus on the people aspect.

---

Drafts:

• Latest [discussion draft] What's New in WCAG 2.2 Draft
• Content reviewed in 26 May meeting: [discussion draft] What's New in WCAG 2.2 Draft - 26 May am

[shawna-slh]

Suggestions from EOWG 26 May:

Brief text:

• +1s to not having DLs. +1s to one point for what, instead of separate ‘objective’ and ‘author task’.
• For the why, have an example user situation and need that is more specific than disability group. e.g., for focus not obscured, something like: ‘Some people cannot use a mouse and rely on seeing what has keyboard focus.’
• Consider the heading more. (“Summary” didn’t work for some)

For Understanding docs:

• +1s to put the brief text before the SC wording, that is, at the top of Understanding doc.
• some +1s to drop the suggestion to add the persona quotes to Understanding docs because the styles don't fit (although not consensus).

For What's New:

• Include the brief text, then the persona quotes, then the SC text.

---

Drafts:

• Latest [discussion draft] What's New in WCAG 2.2 Draft
• Content reviewed in 2 June meeting: [discussion draft] What's New in WCAG 2.2 Draft - 2 JUne am

---

For further consideration:

1. Section heading. (some ideas: In Brief, Summary, Briefly, Overview, Outline, Synopsis, …)
2. For the two points that are the what and the why, the latest draft has two bullets and the second starts with “Why:”.
   2.a. Bullets as <ul> rather than <dl> or <p>?
   2.b. Start with “What:”?
   2.c. Start with “Why:”?
   2.d. Other ideas?
3. Wording for each of them…

[shawna-slh]

Suggestions from EOWG 2 June:

• Keep "In brief" as the section heading.
• Use <ul> with 2 items of short succinct sentences, not paragraphs or <dl>
  [later idea: make them indented and hanging after What and Why like Problem and Works Well ... and could do the same thing with dt and dd inline]
• Start items with "What:" and "Why:", probably bold.

Note: We still need to review the specific draft text of each.

See updated [discussion draft] What's New in WCAG 2.2 Draft

[bakkenb]

Thank you for providing detailed background, draft examples (current and draft), and minutes of discussion.

• Personally, I like the title "In brief" as the section heading. I agree with keeping that wording.
• I like "What:" and "Why:" But maybe also consider "What to do:" and "Why do it:" so that it is more of an action to take when people read it. Hopefully it will push them to action. example...

3.2.6 Consistent Help (A)

In brief:

What to do: If you provide help, put it in the same place on all web pages and app windows.

Why do it: People who have difficulty finding help are more likely to find it when it is in the same place.

Additional notes and comments:

• I do think this solution flows better and uses more simple language than the "Objective, Author Task, Key Beneficiaries" headings and terms.
• I strongly believe that the phrase "For Example..." should always start the persona quotes because it sets the brain to know that an example of a "real person / real issue" is about to follow. Keep that the way it is!

Keep at it. This is good improvement!

[shawna-slh]

To clarify EOWG's suggestions at this point:

• “In brief” has “What” and “Why”. Why is a specific user example (e.g., “Some people cannot use a mouse to drag items.”).
• In the Understanding docs, put the “In briefs” at the top, before the SC wording. Do not add the persona quotes at the top.
• In the What’s New docs, put the “In briefs” and persona quotes before the SC wording.

For discussion in 9 June 2023 EOWG meeting:

• “What:” or “What to do:” or “Goal:”?
• “Why:” or “Why do it:”?
• Importance of trying to keep them to 10 words or less?

---

To facilitate review and discussion, here are the currently drafted -- not reviewed and not polished -- whats as “What to do:”:

1. What to do: When items have focus, they are at least partially visible.
2. What to do: When items have focus, they are fully visible.
3. What to do: The focus indicator contrasts 3:1 with the component’s unfocused state and with its surroundings.
4. What to do: For any action that involves dragging, provide a simple pointer alternative.
5. What to do: Ensure targets meet a minimum size or have sufficient spacing around them.
6. What to do: If you provide help, put it in the same place on all web pages and app windows.
7. What to do: If you have data that needs to be entered again, auto-populate it or make it available for the user to select.
8. What to do: Provide an accessible, easy-to-use, and secure method to log in. Don’t make people memorize or transcribe something in order to log in.
9. What to do: Don’t make people recognize objects or information they previous provided in order to login.

"What to do" fits fine with 4-9 as written, yet not 1-3. Perhaps they could be re-written to work well? Or maybe it would make the wording more complex?

[mbgower]

"Goal" might work better if you're looking for a single word category.
As someone else pointed out, "what" as a single word descriptor isn't really that strong, and "what to do" aligns better with the existing "Author responsibility".
Unfortunately, since you're combining two existing lines, "What do do" isn't always working.

I think "goal" might might give you a bit more leeway.

In fact, if we wanted to get super concise and restrict this to one line, "Goal" could replace "In Brief" as the heading, and we could eschew the prefix.

[bakkenb]

Good points @shawna-slh and @mbgower. Thanks for the elaboration.

I still stand by my suggestion of using "What to do:" and "Why do it:" as the best option.

Rationale:

• I don't think you can super simplify to replacing "In brief" with "goal" because you are following that with two different concept sentences. The first giving the person creating actual direction/instruction, and the second giving them the rationale of why it is important to some/all. Without subtitles for each sentence, that would be a cognitive load to understand quickly.
• I also don't think "Goal" is a better option for "What to do" because it is not a heading that leads to action or implementation. It just alludes to that "this should be your goal, try to do it."
• I think that all of the examples should be written in actionable form (like 4-9), instead of cause and effect (like the current 1-3). That way it is clear, in brief, what the creator should do to implement that success criteria, and why.

[shawna-slh]

Suggestions from EOWG 9 June:

• Keep "In brief" as the section heading
• Start first item with bold "What to do:"
• Start second item with bold either "Why do it:" or "Why:" (consensus not reached)
• 10-word limit is a good goal; however, OK to use more words when needed for important clarity

Note: We still need to review the specific draft text of each.

See updated [discussion draft] What's New in WCAG 2.2 Draft that has different options for why:

• 2.4.11 has "Why"
• 2.4.12 has "Why do it:""
• 2.4.13 has "Why users need it:"
• 2.5.7 has "Why it's important:"

Reminder that the What's New document will have the "In brief"s and the example persona quotes.

The Understanding docs — which get hugely more views — will have only the "In brief"s at the top, not the example persona quotes at the top. For example Understanding dragging with In brief before the SC wording:

---

Action item: Please add any other ideas for the "Why" wording to this issue. Then we'll ask for specific input on the options.

[shawna-slh]

To help thinking about whether or not to include Goal, here is the latest proposed text for the 2.1 SCs:

1. 2.4.11 Focus Not Obscured (Minimum)
   Goal: Keep the focused item visible
   What to do: Ensure when an item gets keyboard focus, it is at least partially visible.
   Why it’s important: People who can't use a mouse need to see what has keyboard focus.
2. 2.4.12 Focus Not Obscured (Enhanced)
   Goal: Do not cover any part of the item with focus
   What to do: Ensure when an item gets keyboard focus, it is fully visible.
   Why it’s important: People who can't use a mouse need to see what has keyboard focus.
3. 2.4.13 Focus Appearance
   Goal: Make it easier to spot the keyboard focus
   What to do: Use a focus indicator of sufficient size and contrast
   Why it’s important: Many people can't see small contrast differences, including older people.
4. 2.5.7 Dragging Movements
   Goal: Don’t rely on dragging for user actions
   What to do: For any action that involves dragging, provide a simple pointer alternative.
   Why it’s important: Some people cannot use a mouse to drag items.
5. 2.5.8 Target Size (Minimum)
   Goal: Make controls easier to activate
   What to do: Ensure targets meet a minimum size or have sufficient spacing around them.
   Why it’s important: Some people with physical impairments cannot click small buttons that are close.
6. 3.2.6 Consistent Help
   Goal: Make it easier to find help and support
   What to do: Put help in the same place when it is on multiple pages.
   Why it’s important: People who need help can find it more easily if it's in the same place.
7. 3.2.7 Redundant Entry
   Goal: Make it easier for users to complete multi-step processes
   What to do: Don't ask for the same information twice in the same process.
   Why it’s important: Some people with cognitive disabilities have difficulty remembering what they entered before.
8. 3.3.8 Accessible Authentication (Minimum)
   Goal: Make logins possible with less mental effort
   What to do: Don’t make people memorize or transcribe something to log in.
   Why it’s important: Some people with cognitive disabilities cannot recall usernames and passwords, or type them.
9. 3.3.9 Accessible Authentication (Enhanced)
   Goal: Make logins possible with less mental effort
   What to do: Don’t make people recognize objects or personal information to login.
   Why it’s important: Some people with cognitive disabilities cannot identify objects or recall information.

For others, see drafts off all in briefs (google sheet)

[shawna-slh]

One of my hesitations about the wording of some of the goals is that "easier" doesn't convey the importance for people with disabilities. e.g.:

Make it easier to spot the keyboard focus
Make controls easier to activate

It’s not about making it "easier", it’s about making it possible.

Make logins possible with less mental effort

ditto, it's not about "less effort", it’s about making it possible.

(Having "Why it’s important" does help with that some.)

---

I’m "on the fence" whether including Goals helps make the SC more understandable overall, or if it adds more info to process without adding substantive additional clarity?

[mbgower]

It’s not about making it "easier", it’s about making it possible.

These SCs don't necessarily make it possible for a specific individual to do something; they seek to reduce difficulty -- reduce the number of people who may rely on ATs (or keyboard, for the target size requirement) to perform certain tasks -- so there's a risk of overstating a 'fix' for everyone too.

"easier" doesn't convey the importance for people with disabilities

I guess it depends if you treat it meaning "less difficult"... To me "easier" does not imply something is "easy", just like "better" doesn't imply something is 'good'. We could consider saying 'less difficult' instead, but I don't find that as engaging or as motivating a term.

I’m "on the fence" whether including Goals helps make the SC more understandable overall, or if it adds more info to process without adding substantive additional clarity?

Yep, that's definitely the question. It would be interesting to do some A:B testing.

[shawna-slh]

EOWG 30 June 2023 minutes