<shawn> scribe: Sharron
ribe: sharron
KrisAnne: Any questions about the surveys we sent earlier this week. Any comments or questions?
Shadi: Thank you Kevin for your magic
Shawn: Asking everyone to look at the survey now rather than wait to be sure you read the extensive intro information and ask any questions if anything is unclear.
<shadi> https://www.w3.org/2002/09/wbs/35532/HPWD-StoriesUpdate-1/
<shawn> +1 I understand the user stories survey
<Jade> +1
<Michele> +1
<Laura> +1
<BrianE> +1
<kevin> +1
+1
KrisAnne: We appraciate all the work that you've done Shadi
<shawn> https://www.w3.org/2002/09/wbs/35532/evaltools_butterfly/
KrisAnne: I am going to take a big deep brath when we get this submission form and the list itself published. The data in the surrent list is just to provide structure. Once we get permission to publish and we have the submission form, we'll oublish a list with real data to replace the current dummy data.
Shadi: I am super excited about this. Happy to have it finally ready. I have submitted a couple of issues and realize I am late to the table. I ely on the Chairs to determine if it is appropriate to reopen discussion. I did not understand how we arrived at the terminolgy around the checks. Is it possible to have more thorough discussion.
KrisAnne: I will look through past discussions from monites, we have had several deep discussions about what to include so when I find that rationale, I will get your thoughts on those.
<kevin> qq+
<Zakim> kevin, you wanted to react to shawn
Brian: I raised this issue previously and wonder how we address technical violations? For example, the expandable filters have nested items that violate WCAG, I beleive.
Kevin: It's been reviewed. If
there are violations that remain, please raise a PR and we will
address it.
... I'll try to do the survey with that in mind.
Shawn: Since there are issues, we won't be able to do an approval to publish survey.
Kevin: We don't know that it is NOT ready to publish once we review Shadi's issues.
Shawn: May want to change it to another Thorough review - will let the chairs decide.
Kris Anne: OK we'll review the status and let you know.
Kevin: Review of the original
prototype at AccessU - thanks to Laura and Brian for getting
that done and Knowbiltiy for providing space. We received much
useful info, Using that feedback I came up with more than 30
things we might check. Working to prioritize, I have created a
sheet to allow the group to see if you agree with my
prioritization.
... we are now trying to address which of these will we include
in the "Easy" checks since som are not so easy. This will allow
us to determine what to actually develop and right up and what
we might not want to include.
<shadi> q
Kevin: let me know if the
isntructions make sense and you know how to use the scoring
sheet to help create a score that will help us make that
determination.
... high scores will mean a higher priority to include. In
terms of providing feedback please feel free to add a column to
the right, comments are welcome. If you're not comfortable with
that, you can sedn email.
... another column is about grouping - do we have all the
chacks on a page, group them by type, have single checks on
each? How many checks should we include - what is too many,
what is too few.
<Zakim> shawn, you wanted to tweak position
Shadi: Wondering if the impact should be more weighted in both directions. If something has low impact and we only have a limited amount of checks to include, maybe that should be more important.
<shawn> Sharron:Easy was a factor before
<shawn> previous https://www.w3.org/WAI/EO/wiki/Eval_Analysis#Criteria_for_checks
Sharron: "Easy" was a determining factor
Shadi: Yes but if something is low impact, doesn't it just create noise? I would prefer to have few checks with high impact than many with low impact.
Kevin: We could easily change the
weighting and impact is an important consideration. How do you
define it is a good question and we are doing finger in the air
guess work and why we are pushing it out for broader review. So
if we want to change the weighting, let's decide that
now.
... Does anyone else support the suggestion to increase the
weight of impact?
<shawn> qq+
Michelle: Should they be Basic Checks rather than Easy Checks? More of an intro to basic issues rather than ease of performing.
Kevin: The requirements themselves define this resource as somthing that allows an easing into checking for accessibility issues.
Shawn: So it is a slightly different use case. We found in the user testing we did that the easy part is important to maintain.
Michelle: That would mean that impact hardly matters.
Rabab: In my opinion there are two things - easiness but there is also a need for a baseline check that would be a larger set of checks to do.
Shawn: This is not that baseline review. We may need to remind people of the purpose. Simply to allow non technical people to have some place to start.
Shadi: Now that I understand that it is someone starting up with accessibilty and taking baby steps, easy things to do to encourage them, I am swayed a bit. But maybe there are two rounds so that impact is considered. By reweighting the medium and high impact will automatically get to the top of the list those that are easier to fix.
Kevin: If we weight impact more, the higher impact items will come to the top and that may be problematic if the top items are less easy.
Brian: I want to agree with weighting the impact. If using it in procurment for example, you want to check things that have high impact as you decide on product. We have to choose and limit we need to surface the ones that have high impact.
Kevin: I will play with this but want to be sure we don't give impact an overwhelming weight
<shadi> +1 to Michele
Michelle: The difference between identifying errors and fixing them is significant. How is that addressed.
Kevin: The requirements do not address the use case of remediation
Michele: If we're not focused on remeidation, why ahve a column about ease of fixing?
Kevin: We want to avoid
introducing despair. There are certain things that once you
look at the issue, it becomes quite clear how to fix it. It is
easy to determine there are no cpations for example and so the
test itself points to the solution.
... others are more complicated and so we want people to
understand the complexity of the repair.
<Zakim> shawn, you wanted to note maybe +common, -fix (previous https://www.w3.org/WAI/EO/wiki/Eval_Analysis#Criteria_for_checks) and to ALSO say fix difficulty little or 0 weight --
<shawn> Severity of barriers - impact on accessibility
<shawn> Common accessibility barriers (what we see often as mistakes in web pages)
<shawn> Easy to understand
<shawn> Not complicated issues (not if lots of debate on forums)
<shawn> Pass-fail not complex;
<shawn> Not likely to give false positive or false negative
<shawn> Checks that clearly related to specific WCAG success criteria
<shawn> ? easy of fixing
<shawn> ? has good example in BAD
<Jade> +1 to getting rid of fixes for this resource, it's often out of the control of the person evaluating anyway if they're procuring something off the shelf or it's third party.
Shawn: Given the use cases for this, we don't want to focus at all on fixing. In terms of the analysis, it should not even be on there at all or else have little or no weight. Another thing is that the criteria for the checks from before were focused on ease of checks, not likely to give false negatives, etc but not focused on ease of repair.
Shadi: The frequency or common-ness of the error is less important but is there a consideration of for whom the barrier is high? The fixes seem like scope creep. My suggestion is to start with the list of highest impact and then the ones of those that are easy to check will give you a good short list to consdier.
Kevin: I thought that ease to fix was helpful, but can set to 0 and we're left with impact, difficulty to explain the test, and ease to perform. Remember we are not creating a definitive list but doing that first selection.
Shadi: So do we even need to do the scoring, can't we shortcut by just starting with high impact and if those are easy to explain and perform, we have the list. Then can look at medium impact, etc
<shawn> +1 for using this spreadsheet for EOWG to include their comments
Kevin: The spreadsheet is meant to shortcut those long discussions.
+1 to using the spreadsheet
<Zakim> shawn, you wanted to say consider leaving the fix column for interest, yet remove from the weighting (so maybe indicate that)
Brian: I think we now have a good foundation for going forward and now we need to vet the other evaluations - the actual individual scores.
Shawn: This is a basis for us to work on a straw proposal.
Jade: I am thinking of the use cases, procurement etc. Would it be useful to include the amount of time for each check?
Kevin: Can you capture that in a GitHub issue, nt quite related to this but how long to check is an item we could add to the info.
<shawn> https://github.com/w3c/wai-intro-wcag/issues/197
Shawn: Look at the GitHub issue flagged in the agenda...will apuse to allow you review and shift your thinking.
<shawn> scribenick+ krisanne
Shawn: Is that you recollection from last week? I used that discussion to make a first pass. When I went to make the sections into bullets and took another few suggestions, I found I could merge two into one. I did not find how to include personas withut useing the persona quotes. If you look at the discussion graph of ideas, we can consdier them together.
<Zakim> kevin, you wanted to ask if we hadn't discussed just removing the titles ('objective', etc)?
Kevin: I thought we were getting rid if the three section titles, not jsut as headings but even the words.
Shawn: There are two versions -
an AG approved current version and a draft idea for how to
change that to another presentation format. It is some place to
start for discussion. There is a Summary, a Why section, and
examples.
... open now for brainstorms.
... take a look at the draft ideas, don't wordsmith the details
yet - look at structure and the quotes, etc
Brian: The two line summary, the second line should be a more general statement with examples below, More generalized in the summary.
<kevin> +1 to the idea that the 'Why example' repeats the actual persona example
Shawn: One of the ideas was to do away with the personas. I agree with what you're saying and wonder if we may want to have summary as one line and then the persona - is that too much?
Brian: There is the risk that the persona will narrow the focus and people may not recognize that they are looking at the SC they are trying to understand.
Michele: Bullets drive a different kind of content in my opinion. Can give short paragraphs of descriptions and then a link to the personas. THis is about x, it helps people such a y
Brian: And then can give the example.
Kevin: As the example of some people don't use a mouse - a more general statement that steps away from the specific persona.
<kevin> For example, for 2.4.11 - "Some people do not use a mouse and rely on seeing what has keyboard focus."
Shawn: What if we have - what to do, the why, and then the persona and then the perona quote works well like we have?
<krisanne> Michele: Don't see the need for the "reporter" and the "works well"
<kevin> +1
<krisanne> ... that seems out of place to me.
<krisanne> ... not tied to a persona at all. The why in general.
<krisanne> Kevin: I think it adds a lot to the top and distracts from the success criteria itself. not just a summary - its a summary+
<krisanne> Shawn: so for the understanding documents what do you think about putting the persona in the "who it benefits" section.
<shawn> https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum
<krisanne> shawn: for understanding docs - summary at the top and persona quotes there? or do we not want the persona quotes at all?
<krisanne> jade: why would you not want to highlight the personas?
<krisanne> shawn: these are understanding docs, so to understand the SC, what do you need to help you understand.
<krisanne> Jade : keep it in the What's new
<shawn> https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/#guideline-24-navigable
<krisanne> Shawn: these specific quotes - are they the issue?
<krisanne> Shawn : AG approved putting them down in the benefits section. are we ok with it, or do we want to suggest to move it or not put them in at all?
<shawn> KrisAnne: trying to connect accessibility to people
<shawn> .... need to communicate why
<krisanne> kevin: the way the quotes are being formatted makes it messy. Make it simpler and humanize it.
<Zakim> kevin, you wanted to argue about 'Summary'
<krisanne> ... i think the layout is what's bothering me. I don't think the "problem" "works well" headings work well for the benefits section of the understanding docs
<krisanne> jade: in the understanding doc, the style of having a quote in the middle of the dry guidance, we can have the quote to humanize that.
<krisanne> Laura : the understanding docs, the tone and writing style is more formal and the quotes and conversation doesn't flow well with the understanding docs. So it would have to be rewritten
<krisanne> ... maybe we can include what we want to say with the quotes in a more formal way.
<krisanne> Shawn: does anyone have the bandwidth to take up the rewrite?
<shawn> <crickets>
<krisanne> Shawn: So we suggest the persona quotes do not go into the understanding docs as they are written.
<BrianE> +1
<krisanne> +1
<Laura> +1
<kevin> +1
<Jade> +1
<Michele> +1
<krisanne> Kevin : I'm not 100% on using the word summary. Its not an easy explaination for something that is complicated
<krisanne> Shawn: it needs more discussion and we can put it on a Github issue and get people to chat separately.
<krisanne> Shadi: *speaks in German*
<shawn> +1 that we need to consider something other than "summary"
<krisanne> ... are we collecting all of these thoughts for future improvements of the Understanding docs or WCAG 3.
<krisanne> ...even a wiki where we can just jot down issues as they arise for the future.
<kevin> Couple of quick thoughts on alternatives to "Summary": Overview, Outline, Synopsis
<shawn> please see agenda list https://www.w3.org/WAI/EO/wiki/EOWG_Meetings#Agenda
This is scribe.perl Revision VERSION of 2020-12-31 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/don/done/ Succeeded: s/SHarron: /Sharron:/ Succeeded: s/puching/pushing/ Succeeded: s/ask question she put in Zoom Chat since she's not on IRS yet :-)// Succeeded: s/lsit/list/ Succeeded: s/nt recongize/not recognize/ Succeeded: s/form/from/ Succeeded: s/* gesundheit// Present: Brian, BrianE, Jade, Kevin, Laura, Michele, Rabab, Shadi, Sharron, Shawn, krisanne Found Scribe: Sharron Inferring ScribeNick: Sharron WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 26 May 2023 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]