<shawn> [introductions to Fred Edora, Weiss Center]
Shawn: From agenda, new comments
for Summaries of SCs - https://github.com/w3c/wai-intro-wcag/issues/197
... For more background, in the What's New in 2.2 resource we
have persona quotes...
The Acccessibility Guidelines Working Group had separately been working on summaries for each SC...
We thought that was great and had suggestions for making it even more readable (for SC and What's New)...
Mike Gower (primary lead on writing the summaries) liked the idea of the EO contributing...
So we're currently working on finalizing our suggestion for the presentation of these summaries
<shawn> summary of issue and discussions: https://github.com/w3c/wai-intro-wcag/issues/197
<shawn> discussion draft: https://deploy-preview-196--wai-intro-wcag.netlify.app/standards-guidelines/wcag/new-in-22/#current-2411-focus-not-obscured-minimum-aa
<shawn> example dragging https://deploy-preview-196--wai-intro-wcag.netlify.app/standards-guidelines/wcag/new-in-22/#current-257-dragging-movements-aa
Shawn: Our current suggestions in
the draft changed the current wording to something with "What"
and "Why" with brief statements for both.
... Now I have polishing questions given we're fairly set on
this overall What/Why structure.
In GitHub, Brent commented that instead of using "What", use "What to do". Also instead of "Why", use "Why do it". Thoughts on that?
<shawn>Example: "What to do: For any action that involves dragging, provide a simple pointer alternative."
Kris Anne: There's a mention of "Goal" versus "What to do"
Shawn: That was from Mike but before he realized we wanted to keep the Why - it was a timing mix up in the messages
Kris Anne: Okay
Michele: I like "What to do" and "Why to do it" assuming the text matches those headings
Sometimes SC criteria aren't super direct, they're more about the outcome than a directive
But overall I like it
Kris Anne: Agree with Michele, I like the "What to do" but want to make sure it makes sense...
It's what are you doing and why are you doing it, it makes it sound less stiff and more welcoming
Laura: Also agree I like the direction and think it helps with that accessibility is only for screen reader users
Getting detailed in who this helps and why is really good
Will help them understand the guidelines better
Kevin: What purpose do the phrases "What to do" and "Why to do it" hold?
Can we drop them all together and make this conversational?
Kevin: I mocked up the What's New page to demonstrate this [shares screen]
I wanted to look at this without the words in the bullets
Shawn: Let's look at an Understanding Document. We've been looking at the What's New but more important are the Understanding Docs...
Imagine this is right under the main heading of the SC title - do we need In Brief and then the What/Why text?
Laura: I understand Kevin's point but don't agree. People tend to skim and the text helps target people's reading.
<kevin> +0.5 to Laura's comment
Michele agree, think the dropping the bold phrases makes the text blend in to much, and it will be skipped over.
Fred: I'm with Laura. I just need to know what to do when someone asks me to address something and this text will help me jump to that.
Laura: Especially on development teams, they are pressed for time plus trying to quickly learn. Seeing this text will help them quickly get these points.
Shawn: When doing usability testing in AccessU, several people were asking for "why"...
An additional group in Europe said the same...
The why is in there but people didn't see it...
In one version, there was a heading like "Benefits of this" or something like that but missed it - didn't realize it was the Why...
Laura: I'll back you up, once they realized it was the Why they were happy.
Shawn: The 2 bullet points are also totally different, so the text clarifies that the bullets are showing they are 2 different points
Kevin: This wasn't a strong suggestion so I'm fine if we leave the words. However, I mocked it up anyway. [shares screen]
Kevin's screen now shows "In brief" with "What to do:" and sample text plus "Why to do it:"
Shawn suggests changing to "Why" only to look at options
<shawn> [ looking at mock-up of Understanding doc with at the top In Brief: ... What to do: ... Why: ... ... then later with "Why do it:"]
Kris Anne: Definitely will help the skimmers and also give me the language to help my team
Laura: I like that it's right up-front...
When trying to educate people (developers and others) it's best to have someone do a live demo...
In the event you can't have someone do a demo, this feels like it gives a concise substitute
Want to keep reinforcing that it's not for screen readers
MicheleI like why do it. Not just why. Feels to jarring to be different. Why do it: set me up better for a person story.
Mark: Agree with Michele. I like adding "Why you should do it" - the Why is too short and a bit jarring.
Kris Anne: I like them to match with "What to do" and "Why do it". It's a sentence fragment but it's more descriptive like Michele said.
And it's still inciting an action which is what I want.
Fred: Agree, parallelism is important here.
[Kevin updates it on his screen]
Shawn: (chairing hat off) "Why do it" seems wordy and awkward to me.
Kevin: How much agreement do we need for now?
Can we open up the specific wording for more input?
Shawn: Like a survey?
Kevin: Yeah, maybe
Shawn: If everyone else loves it I could let it go. Agree to get more input.
Kevin: Really it's staying "what I need to do and why I need to do it" but we're shortening...
and to Fred's point, I like the parallelism.
Laura: I'm okay with just "Why"
Fred: I can sleep at night either way
Shawn: The "What to do" rewrite works in some cases but not all
I changed the wording in GitHub as examples, but the first 3 examples don't work well...
For example, "What to do: When items have focus, they are at least partially visible."
<shawn> "What to do: For any action that involves dragging, provide a simple pointer alternative."
<kevin> "Ensure that when items have focus they are partially visible"
<shawn> What to do: When items have focus, they are at least partially visible.
<shawn> What to do: When items have focus, they are fully visible.
<shawn> What to do: The focus indicator contrasts 3:1 with the component’s unfocused state and with its surroundings.
Shawn: Do we think they're fine, think they can be tweaked, or do we change the opening wording to just say "What" when the additional wording may not fit?
Shawn: For some of the criteria, having it say "What to do" aligns with the following statement very well as in "What to do: For any action that involves dragging, provide a simple pointer alternative."
The question is, what happens when the language doesn't flow so well?
Laura: Let's make the description of "What to do" more actionable where possible...
I know it's hard to write them in the same way and we know it may not always be doable
Fred: The first 2 examples seem like "why" rather than "what". Perhaps it's more like things to think about...
That is, if it's not a clear directive on what action to take, perhaps they are targeted questions to ask their teams.
Kris Anne: Agree with Fred. Examples #1 and 2 don't currently work but also I think we could rewrite them to fit.
Shawn: AG is writing these for all SC's
Michele This was my fear when I said "what to do" some do not have a direct action. However, it will force us to come up with the actionable thing to make something accessible. What to do can take on different actions.
<kevin> +1 to encouraging action phrases
Kevin: Agree with Kris Anne, I
think they can be rewritten. I put an example earlier such as:
"Ensure that when items have focus they are partially
visible"
... To Michele's point, we should be trying to come up with an
action for folks.
Shawn: Let me try to summarize...
1 - Keep it "What to do" and have the wording be very actionable
2 - There were mixed preferences for "Why" vs. "Why do it" which we'll get more input on
Shawn: Another point: Mike was trying to keep the wording to 10 words max. Do we want to keep doing that, or is it not important?
<shawn>Example of one that's longer that I drafted: "What to do: The focus indicator contrasts 3:1 with the component’s unfocused state and with its surroundings."
Fred: Was there a reason for 10 words?
Shawn: Don't think so
Just trying to be succinct
Kevin: I think 10 is a good target but don't keep hung up on it...
<shawn> +1
<fbedora> +1
<kakinney> +1
The point is to keep you focused on making it short but don't be too hung up on being stricly 10
+1
<Laura> +1
<MarkPalmer> +1
Shawn: That's also what I was
thinking but wanted to get input.
... Final question - the status is that Mike has drafted the
long versions of the In briefs with prior structure (Objective,
Author Task...) for all of WCAG Level A and AA in all WCAG 2
versions...
We now need someone to edit these into the new format including writing more specific Why...
We also need it for Level AAA criteria...
Is anyone interested in helping with that?
Michele: I can help
Kris Anne: Mike has these already written and we're changing to our structure, plus do AAA ones?
Is that the ask?
Shawn: Yes
Kris Anne: If he has most of them written I can work with Michele
Fred: I can help review. I like the action steps idea so I'd like to review it.
Kris Anne: Additional reviewers is always helpful.
Shawn: Okay, I'll update the GitHub issue with our decisions.
<shawn> google sheet https://docs.google.com/spreadsheets/d/1FsKGXi1BrBHBId_ZwKLtloXBZL0GcouQ7c26r-XJLRw/edit#gid=1028262944
Shawn: Reminder that in the Google Sheet there are instructions on what to do..
Since last time, however, we separated items into a "Check the priorities" tab and "Argue for inclusion" tab...
Check the priorities is for things we think will be included, Argue for inclusion are things we aren't currently including so you can make the case to include
Shawn: To level set for new people, we have a current Easy Checks resource that we're revamping...
Kevin has rated possible checks on criteria such as impact and difficulty to improve...
We're now looking for input from EO on these rankings and what to include in the updated resource.
Shawn: The current Easy Checks has 10; we're looking to see in this new version how many we want to have and which ones.
Kris Anne: Is there any more background on what, for instance, we may add more?
Shawn: Some of the items on the current list are not easy, so we were motivated to change that...
Then also some of these are based on 2.0 but with 2.1 and 2.2, there may be new things we want to include...
So we want to give a fresh look and that includes how many we want to include.
Kris Anne: But if we're thinking about how many we should keep in mind that we're not telling people to check all of these items, right? We're just giving tips?
Shawn: It's good to read the goals, target audience, and requirements so you're clear on the purpose...
So Kris Anne makes a good point that this is not a resource of these are the checks you have to do.
Kris Anne: Right, keep in mind this is not presented as "these are the 38 checks you need to do", they are simply avaiable as suggestions (how ever many there are).
Laura: From usability testing,
one professor was commenting that hte order should start with
easiest and that less is more
... For example, form fields is not easy
Shawn: And number of checks came up too
Laura: yes, less
Kevin: I wasn't in the usability testing so I'm just speaking from my experience. With that, I think we should be cautious in trying to cut the number...
Instead I think we can design the page so it's not overwhelming which then can allow more checks...
We can also group checks together by themes as a possibility
Shawn: You can also present it as a "First batch" and then "if you want to do more"...
Something that helps people onboard to a few that are doable and then encourages them to do more...
We can look at options to do that and make it not feel overwhelming.
Shawn: Let
... Let's add to GitHub, and also clarify that we want to make
sure it's clear we're not saying "Just do these 6" - set the
right task
... In the Google Sheet, add a column with your name and then
add your comments for each check
Most people will have comments on the "check the priorities" sheet...
On the "argue for inclusion" page, you only need to comment if you think those criteria should be included
Michele: What comments are you looking for?
Kevin: Do you agree with the rankings (e.g., Impact and Difficulty to Perform)? That's guiding how they are prioritized...
I put items in "Argue for inclusion" based on my rankings, so on that sheet you can write out any ways you may disagree with not including those and/or their general rankings.
Shawn: For example, with Audio description I explained how I didn't agree with the difficulty rankings.
Kevin: Yes, that's the type of feedback I'm looking for.
<shawn> for example -- I'm not sure I agree that it's high difficulty to explain? Many videos have text and maybe it's fairly easy to determine if that text is covered in description?
So again the ask is to go through the Google Sheet and add your comments.
<shawn> https://www.w3.org/WAI/EO/wiki/EOWG_Meetings#Reviews_and_Surveys
<shawn> https://www.w3.org/WAI/EO/wiki/EOWG_Meetings#Outreach_Tasks
Shawn: We're moving towards making it clear where anyone (that is, people not in our group) can contribute to our group...
So we have a new format for Work for this Week that designates "For Anyone"...
So if anyone has comments on how to make that more understandable, let us know...
Because we want to make sure it can be shared with others outside the group.
Shawn: Any other questions?
If not, we'll give you 30 minutes back to start working on the Easy Checks
Thanks for joining us, Fred!!