<shadi> scribe: shadi

Evaluation Tools List

<shawn> open issues in survey -- https://www.w3.org/2002/09/wbs/35532/evaltools_filters/

kevin: been working through the issues from the previous survey
... list hadn't been updated for a while, have the opportunity now through HAN University and other contributors
... most of the work done, doing some polishing then we can publish
... also need to recollect some of the data because not all can be reused
... had an approval to publish survey that resulted in some issues
... most have been addressed but some questions are outstanding
... waiting for some people to submit further information
... others we want to discuss today
... these include: which standards to include, order of the filters, and other minor changes
... previously standards also mixed in some legislations like US Section 508
... suggest we pair it down to WCAG and variations of that

<shawn> Version B with only W3C standards list and without the accessibility checks https://deploy-preview-120--wai-evaluation-tools-list.netlify.app/tools-list/evaluation/

kevin: WCAG 2.0, 2.1, and EPUB 1.1

<shawn> Version A with old standards list and accessibility checks https://master--wai-evaluation-tools-list.netlify.app/tools-list/evaluation/

shawn: want to focus on WCAG, not promote deviations
... assume most will do WCAG too

<shawn> scribe+ shawn

<shawn> shadi: fully agree.

<shawn> ... it was even broader when started 20+ years ago. There were lots of others things

<shawn> ... now WCAG focus agree.

shawn: suggest we make the change and list in the changes section?

BrianE: so move it to question 5?

shawn: yes

<shawn> [discussion of EPUB vs. EPUB 1.1 - decided to go with EPUB 1.1 as it's recommended by W3C ]]

shadi: think we want to promote v1.1

BrianE: EO decided to remove the standards-specific question from the survey, make the change to the standards section (WCAG 2.0, WCAG 2.1, and EPUB 1.1), add it to the 'Other changes' section of the survey and present it to the group for approval?

kevin: yes

Subtopic: Filters

kevin: what order the filters are in, and which ones we want to keep up top
... want to try and reduce the number of open filters
... and match the order to what people use most frequently
... maybe 3 open filters and a "more" filter with others below that

BrianE: does the survey question make sense?

[version, free/paid, type of tool, manual/automatic]

Michele: are there repeat visitors?

kevin: not sure people use it very regularly
... but maybe several times to find a set of tools

Subtopic: Other Changes

kevin: to make sure people agree with the changes
... for example, not showing checks right now
... but collecting the data in case it becomes relevant
... also not going for a filter assistant/wizzard
... hoping to simplify filters instead
... restructured card to make it more accessible and hopefully more usable
... we'll now also add the changes to the version numbers to this question

<shawn> shadi: not sure about collecting data that might not be useful. the question is what is the rationale for the data? how did you get to this list?

kevin: there is a rationale for this list, which we'll present
... comes from testing with users
... users look for specific things
... this is how they came up with this list
... then validated it with two vendors
... we're not sure if this is comprehensive enough
... results from testing weren't so clear

<shawn> shadi: I'll look at the list and respond. I'm not sure this is the right list. If you collect the data, then provide a filter.

shawn: disagree
... there are significant ligitimate disagreement on the list
... want to simplify filters rather than add filters

<shawn> shadi: arguement that we want to simplify the fitlers. don't make people do extra work. or maybe clearly mark in the submission form that it is beta

<shawn> ... or completely remove it.

kevin: like that idea

BrianE: decided to add as β filter

kevin: do we put that alternative idea in the survey?

BrianE: thought it was about indicating to the vendors that this is a β feature

kevin: both, indicating to the vendors and the tools list user

shawn: -1

<shawn> shawn: 0

<shawn> fred: if you release this list, people would trust it

shadi: my understanding is that we can (1) completely drop, (2) collect the data and not present it to users, (3) clearly mark the data as experimental to vendors and users, and continue to refiiner

fbedora: concerned people seeing this list will not question it's trustworthyness
... assume that if it comes from WAI it can be trusted

<shawn> shadi: what if clearly marked as experimental?

shadi: would that change if it is clearl marked as experimental?

fbedora: that would help but people might not question trustworthiness

kevin: not about trustworthiness but more about is the list complete and useful?
... ironically, the best way to get a useful list is to put out an incomplete list and ask for feedback

BrianE: so, do we update the survey to include these ideas?

kevin: yes

<shawn> scribe: Kevin

<shadi> BrianE: we'll work together on providing more context to the survey and update the question

WCAG Success Criteria In brief's

shawn: Mike and Michele will be looking to work together on this piece
... We developed persona quotes to introduce new WCAG 2.1 SCs
... these were well received: partly because of the quotes and partly because of the short summary intro to the new SCs
... This idea was picked up by AG to add to the Understanding docs for the new 2.2 SCs
... EO are now working together with Mike from AG to develop these

mbgower: At the moment they all say 'author task' or @@
... There is a PR to reposition the summary and remove the 'Key beneficiaries'
... There has been discussion of this just looking at the 'what' and 'why'
... I have been looking at retaining 'goal'
... Would love to do a bit of A/B testing to explore the value of each of these

shawn: There are a few questions
... EO had suggested just having 'What to do' and 'Why it is important'
... Mike suggested retaining 'Goal'
... There is a google doc with all the text in it

https://docs.google.com/spreadsheets/d/18oGWkp15s15iCRgPcaf_XwUsF-y2l2voc9CtIeV6PqA/edit#gid=1123742479

shawn: There is also an example of how this might look in the Understanding document

https://raw.githack.com/w3c/wcag/wcag22inbriefEOW/understanding/22/focus-not-obscured-minimum.html

shawn: Finally, there is an example without the 'Goal'

https://deploy-preview-204--wai-intro-wcag.netlify.app/standards-guidelines/wcag/new-in-22/#2411-focus-not-obscured-minimum-aa

shawn: Two questions...
... 1. Should we include the goals?
... 2. What should the format look like?
... (A description list or bullets)

mbgower: Third question might be whether the prefix words are ok.

shawn: Looking at goals first
... Does the goal help with understanding or is it unnecessary information?

mbgower: The goals do ensure that additional information is not required in the other sections

<Michele> I found this article helpful for understanding what Mike is getting at with "Goal": https://medium.com/design-ibm/wcag-2-2-quick-and-simplified-73c3ff66b065

Michele: I am leaning towards including 'goal' as there may be a risk of overloading 'what to do' with 'what it is'. Having 'goal' helps to reduce that - goal covers what this is, what to do is the action, and why it is important highlights the value

<shawn> scribe+ brian

<shawn> scribenick+ BrianE

<BrianE> Kevin: kind of agrees with Michele, but as the goals are written there is a lot of repetition

<BrianE> ... captions is one example

<BrianE> ... sees the value of having goals but would like to see less repetition

<Zakim> kevin, you wanted to say that having goal and what to do is often pleonastic

shawn: I have read all the goals and mostly I lean to them adding more information to process without adding much to the clarity. Some of them though are more useful

mbgower: I can take in the idea of making them addative and not repetative

<Zakim> mbgower, you wanted to say I think focusing on making them addititive and not repetitive

mbgower: I would suggest to proceed with what is in the PR
... This incudes moving the information to the top, which still needs to be approved by AGWG
... Might also be valuable to ask AGWG about the goal

BrianE: I like the goal and how it is structured. Removing the repeatativeness would be ideal

<shawn> ach m

Michele: While I understand there could be repetition we could use that as an opportunity to clarify some of the terms.

<shawn> qi later

fbedora: I like Michele's idea. It might be useful to think about 'definition' rather than 'goal'.
... That might align with 'what to do' and 'why'.
... I am just trying to avoid making assumptions about what people might know

mbgower: Just as Michele spoke I had thought about going back to definitions so that is worth thinking about

shawn: The 2.1, 2.2 stuff is already out there and being commented on. So we are taking an iterative approach.
... One idea is to add this in stages: 'why this is important', then refine and add other things going forward.

<Zakim> shawn, you wanted to ask about priorities

shawn: Would this work as a next step?

Michele: That might work. I wasn't caring for 'Some people need...'. The 'some' can read that it is optional in some way.
... Might be worth looking at the 'why this is important' with this idea in mind.

mbgower: Not sure if this is in survey but we have the 2.2 changes and the WG are aware that this is an iterative process.
... We will get input on this as we go forward

shawn: Next steps: Mike and Michele to look adding 'why it is important' for 2.1, once drafted we will look at any opportunity for usability testing

mbgower: We tried this in Google docs but the change management but that doesn't work in Google sheets
... Might be better to move it into Google Doc to improve discussion and document history

<BrianE> kevin: other option for testing is to send out email to EO to share with network and collect feedback through google form

shawn: Do people care about the format?

<Zakim> kevin, you wanted to suggest options for testing

shawn: To support skimming we included a haning indent. This may help with focus.
... When it is formated as a bullet, there isn't the same hanging indent.

Michele: I like the visual styling of the DL but this may add more to assistive tech
... Might it be possible to use CSS to style like DL but have code as bullets

BrianE: The DL looks a bit visually heavy

mbgower: We might have a cake fest here. We could potentially use CSS to style for best visual perspective and review how the underlying code is put together.
... We can also iterate across the presentation in the same way as we are doing the content.

shawn: We will continue to iterate this and review

Michele: My main concern is the underlying code. Will need to ensure that the look is accepted before any usability testing.

mbgower: Lists are strange as there is no title. DL does have a pairing of the term and the list content.
... Worth checking options with screen reader users

shawn: There was some concern from AG and EO about people taking the in brief wording separate from the SC
... We can explore whether this is likely to be an issue. There is some evidence that that may not be as significant issue as thought.
... There is a risk of over-simplication that we can keep an eye on

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/[ discussion of EPUB vs. EPUB 1.1 ]/[discussion of EPUB vs. EPUB 1.1 - decided to go with EPUB 1.1 as it's recommended by W3C ]]/
Succeeded: s/ shawn: don't think we should add version number/ /
Succeeded: s/ make the change and present it to the group for approval?/ EO decided to remove the standards-specific question from the survey, make the change to the standards section (WCAG 2.0, WCAG 2.1, and EPUB 1.1), add it to the 'Other changes' section of the survey and present it to the group for approval?/
Succeeded: s/comnpletely/completely/
Succeeded: s/agreument/arguement/
Succeeded: s/ on the content since the bullet is the first item scanned//
Default Present: Brian, Shawn, Shadi, Kevin, Fred, Michele, mikeGower, mbgower

WARNING: Replacing previous Present list. (Old list: Shawn, Brian, shadi)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ Brian, Shawn, Shadi, Kevin, Fred, Michele

Present: Brian, Shawn, Shadi, Kevin, Fred, Michele, mikeGower, mbgower
Regrets: @@lots-o-regrets
Found Scribe: shadi
Inferring ScribeNick: shadi
Found Scribe: Kevin
Inferring ScribeNick: kevin
Scribes: shadi, Kevin
ScribeNicks: shadi, kevin

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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.)