Accessibility Guidelines Working Group Teleconference

14 May 2019


alastairc, Chuck, stevelee, Detlev, Raf, MichaelC, johnkirkwood, Lauriat, JakeAbma, Gilbert, Arthur, david-macdonald, mbgower, Jen, Kunal, Rachael
Bruce, Laura
Detlev, Rachael_, alastairc, mbgower, Rachael


<Detlev> scribe: Detlev

<Chuck> I'll be backup

Google research & experience working to the non-text contrast SC

Recording of this topic

Michael Gilbert: (sharing desktop)

scribe: Introductions, goal / Shadows and outline study / Material design / Core a11y

<alastairc> Noting that slides will be described / not relied on, for those who can't see them.

scribe: taking a look at a11y and usability of components @ Google
... will share presentation via sharable link (or Shawn will work on it)

Jen: (introducing herselfGoogle UX team)

Kunal: introducing himself, senior interaction designer (Google)

Shawn: introducing material design @ Google - integrates components across products, open source
... share study, results, findings, emphasise how they can be useful for WCAG

Michael G: Aims to get feedback from group id approach is useful

<Lauriat> Copy of the slides: https://docs.google.com/presentation/d/1CFNxozlyO1lmiyRVCFuhQ_0t2c5QTLskY03CCeTpUuA/edit?usp=sharing

mike: Can it be recorded?

Michael G: Yes

(Michael Cooper tuning on recording)

Michael G: Recent study focused on identifying a11y of components in material design (strokes, outlines contrast ratios)

scribe: buttons in dialog, 'chips' = pill-shaped rectangles reflecting user input
... Question was what contrast are needed for stroke and shadow outlines
... referring to WCAG contrast ratios on AA and AAA
... Focus was on non-text elements, harder to understand what needs to be done to align with standard
... requirement is 3:1 for non-text contrast - it is not spelled out what is required to *identify* component

<david-macdonald> can detlev mute?

scribe: aim that those characteristics required t o make components identifiable and be perceived as interactable
... meet the WCAG requirements

<Zakim> mbgower, you wanted to say but wouldn't you just use an alt=""?

Michael G: 15 participants of trusted tester panel, meeting once a week over 3 weeks

scribe: presenting mock-ups of new designs

36 separate interviews 18 hrs spent answering two simple questions

scribe: wanting to make sure to ensure good experience and compliance to WCAG
... all had low vision, most were legally blind
... some used magnification, some Screenreader, some braille- some even using several access techniques combined over the sessions
... John Kirkwood: Anyone form the community of aged people or those with cognitive impairments?

Michael G: Focus was low vision, but some were elder users

scribe: aim to ensure parity to dempgraphics in US, always elderly users, some cognitive
... study focused on comparison of different designs, and task-based approaches ("where would you click to compose a message?")
... then comparing and contrasting different versions to compare for example stroke vs. shadow, strong and low contrast, light / dark mode etc
... trying to keep questions simple
...findings: identifiability: all participants could identify components (no difference between stroke / shadow) - given enough time (so it might have taken longer for some)
...interactability: 2 participants indicated that components were not interactable with no outline at all (of 168)
... so a very low number

David: question about "given enough time" - di users get it after some longer effort? Getting at the bracket used

Michael G: On a comparison task, about 5 secs initially, then more - framing the current context - exploration on desktop may take 10, 20 secs or longer when they zomed in / scrolled

scribe: mobile exploration was much quicker because display is smaller

David: Trying to understand the task, the focus on one control or a wider context

Michael G: There was little ambiguity once the control was spotted

scribe: people could differentiate text boxes, links, buttons - did not through people
... there is additional content in the slides - one aspect most relevant is the question if shadows / outlines are required for identifiability / interactability? The answer seemed to be that they aren't - only in a very low percentage of cases
... there are additional attributes of components that help identifiability: font color, weight, fill color, elevation, familiarity with language (because they say "OK" or "close"), familar patterns due to recognised icons etc
... three choices imply thes are buttons, etc -- all these aspects had an impact on identifiability / interactability
... three evenly spaced things at the bottom of a modal dialog, or understanding derived from character of the app (messaging)

David: Did all components meet contrast requirement of 3:1?

<alastairc> David - lots of different examples, even just the published ones have a lot of variety, and I think they tested more, see https://material.io/design/components/chips.html#input-chips for chips

Michael G: three scenarios were tested: no contrast (?), standard contrast, high contrast

Kunal: Sometimes container color was same as background color but font color was different to isolate shadows and outlines

<Zakim> david-macdonald, you wanted to ask if the components tested had 3:1 contrast with adjacent colors.

mbgower: When there is is no outline, the color contrast is not sufficient - not clear how many things in combinination impact perception

Michael G: That was a finding - that a lot of other things impacted identifiability

Michael G: Could still be studied in a more targeted way

scribe: many compounds have to be dealt with, including app context
... can't say if things like elevation is primaril yresponsible but that it dies play a role
... what are the next steps that would be most productive in discussion between Google and WCAG?
... SC 1.4.11 question: visual information "required to identify" and the "not modified" part for native controls
... "visual information" is not operationalized - leaves room for interpretation
... study should help codifying what "visual information" is
... second question is what is "to identify"

<Zakim> alastairc, you wanted to ask what you'd want to codify, without dictating design beyond the core accessibility scope

AlastairC: Do you want to identify the traits of components that are addressed (as in rasdio buttons etc.) Did n't want to be too restrictive

Michael G: Attributes from the larger context were part of it - so it is a question for the group because identifiability dioes not hinge on contrast alone, so the boudary between component-specific and contextual should be defined better

scribe: aim is to be comfortable that Google is pushing towards alignment - things shoud be as contrecte as possible - understand some level of generality is needed

<Zakim> mbgower, you wanted to say did the context provided by the Understanding document help contextualize things for you?

mbgover: To what degree did the understanding doc help contextualise the normative text of the SC?

<alastairc> How much did this help, but what questions were left? https://www.w3.org/WAI/WCAG21/Understanding/reflow.html

<Lauriat> This one, I think: https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

Michael G: It did help - documentation is used a lot - but there still i asa need to codify that into precise statement for the design

<david-macdonald> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html

scribe: if it was more codified in AG documentation it might help

Kunal: (rephrasing Mike's question) - examples helpful for application . teams that use the design system which try to match visual styles they are working with with the examples in the understanding doc
... what are the elements that are most important for the particular interaction they are working on - this SC can lead to a deeper self-check and evaluation of own approaches

mbgover: Is there value in creating a bunch of examples and let the working group assess if they fail 1.4.11?

Michael G: Could be valuable - people might consult such a set of examples to identify good solutions or inform other approaches - would allow a more systemic way of interpreting guidance

scribe change?

<Rachael_> scribe: Rachael_

<Detlev> mbgover: Confirms issues at IBM tackling graphical objects and contextual aspect that impact on identification beyond contrast

Michael G: Other attributes come into play that go beyond nontext contrast but come into play when considering which is more important.

Alastair: Wrap up. Follow on from previous, we have tried to abstract in most of the cases and did go through several design systems including Google Material and ensure that there is at least one version of each one that would pass.
... if you have examples of which were still left out, that would help.

David: It is really hard to make this SC. Non text contrast is hard to measure. I'd like to hear more about what you found about the cognitive awareness of a button. What are your thoughts of what we could codify across websites?
... proximity? Border on slide 31 but as soon as you put a border around it there is a requirement. If you have other things, let us know (color, etc). Expanding info gathering to include cognitive disabiliites and color blind is also important.
... The Canadian government tested maps that had color. Those who were not color blind found color maps valuable but those who were color blind did not.

Jen from Google: I would like to follow up on how to collaborate to do future research. Do you all do your own research?

Alastair: W3C is a member organization. Low vision taskforce did a lot of research which informed 2.1.

<Zakim> MichaelC, you wanted to mention RQTF

Michael_C: This working group raises questions but does not do its own primary research. There is a research question task force which IDs possible questions and then tries to stimulate research in the field. They could work with you.

Alastair: The group will digest and likely have follow up. Would a public list be OK for that or would you prefer keep the conversation to the working group?

Michael G: I defer to your standard practices. I think public is OK.

<mbgower> Thanks for the presentation!

Alastair: I will send a note with an introduction. Please reply to that with the presentation link. Thank you very much. I am looking forward to thinking about this more.

Michael G: I would like to work with you all to figure out how to spin up the next study to ensure that we add value internally but also to the group as well.

GitHub issue management, resolving AGWG member comments/questions

Alastair: a quick answer is to have someone join the WG and low vision task force.
... Quick item on github issue management. We have 180+ open issues in github. Some of these are discussion items which historically would have been email discussions. they don't have an action. With the github process we need to answer everything.
... Michael and I have been discussing this and we think it would be helpful to add a "discussion" label to let us know there isn't an action. It makes triaging the queue easier.

<Detlev> @Alastair: was it not "question"?

alastair: We can let it drop after a while.

<Detlev> ok

alastair: Detlev, I renamed the question into discussion because sometimes a question leads to an action.

New techniques & issues survey ( https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/)

Alastair: We had a very large survey and unfortunately not too many of the questions were easy. We organized to prioritize the techniques.

Failuretechniques for input mechanisms

<alastairc> https://raw.githack.com/w3c/wcag/48ba95d4151b4ffa93ce773949ffbe2cdf669b93/techniques/failures/F97.html

Alastair: Rachael had asked that the description include a statement about the fact that some users need input other than touch screen. This is in the understanding document. Are you ok with it only being in understanding?

<johnkirkwood> sorry

Rachael: I am OK with it but it seemed like a gap.

Alastair: Jake was talking about the example of hiding buttons. I am unsure Jake what you are recommending.

Jake: If you allowed a swipe on a carousel with a pointer device, would it pass. The title of the failure doesn't specify.

<alastairc> To do: to specifiy that touch events are used in second example.

Alastair: It seems like a fairly easy add.
... I had a fairly easy add. Michael Gower had a concern that the second example may not be a failure. I wasn't sure how you would seperate out the mouse and keyboard.

Michael G: If you fail a mouse implementation, it is easier than if your failure technique covers multiple modalities.

Alastair: I saw this as touch or keyboard or mouse but I see Patrick's point.

Michael G: As it stands right now, part of this failure applies to other SC and part of it doesn't.

scribe: It is a bit awkward to talk about keyboard when trying to talk about gestures.

<alastairc> To do: Separate out the keyboard aspects, as per Michael's comment.

alastair: we need to avoid looping back. The other to do: Separate out the keyboard aspects.

RESOLUTION: leave open pending updates

New technique: Using native controls to ensure up events (PR 726)

<alastairc> https://raw.githack.com/w3c/wcag/tech-up-event/techniques/general/G211.html

Alastair: 6 people thought it was ready for publication with changes. Several people picked up on patrick's point about the button not working. Detlev had the most substantial point about using up event which is in the glossary. Detlev, is that editorial?

Detlev: I guess so.

Alastair: Being more consistent across those.
... Jake had an editorial change and then a proposal to rewrite with mulitple scenarios. Why would we cover all these techniques if this isn't a failure?

Jake: When I read the SC and the conditions for the SC, I thought this needed more work to relate it to the normative text. I think it may need to be rewritten to be clearer.

<Zakim> mbgower, you wanted to say that the SC only needs one of the bullets to meet, so we don't need to make it inclusive

Mike_G: Jake, the wording of this SC is at least one of the following is true. Only one needs to be met. This SC is callign out the up event to meet it. This isn't all of them becuase it is one of the following is true.

Jake: I understand but the proceedure isn't a direct match. I can't find the word irreversible in the understanding document so there is a mismatch.
... there must be a better match.

<alastairc> scribe:alastairc

<mbgower> scribe: mbgower

Detlev: I said a similar point to Jake in regard to the test procedure.
... I wasn't entirely sure what it meant about "irreversible"

Alastair: I agree the irreversible is odd. We often start with a procedure pre-amble, so I don't think that is an issue.

RESOLUTION: Leave open pending updates.

Understanding update: Pointer Gestures clarity (PR 714 / 725)

Alastair: I created a new PR to keep sliders in scope and added some material on short/long slider gestures.

AWK: If the SC is talking about why gestures are problematic, it comes down to an implementation
... I am not going to fight this too hard either way, but I felt like this is like a point Mike Gower was making last time.

Detlev: I realize this was a resolution, but felt we were a small group and it would be okay to bring it back up with some more information.
... I identified some dragging that required direction to trigger.
... I looked at swipe to reveal, which was not in either camp, and found the distinction you came up was difficult to draw.
... Finally, I found the rationale would be fairly straightforward if you just said 'anything that is a clear drag and drop' would be out of scope and everything that behaves in a constrained way is in scope.
... That would include dragging gestures.
... I would argue to keep this very important group of controls in scope, and it does affect people with disabilities.

Alastair: I'm taking AWK's point about how it is implemented.

<Detlev> mbgover: 2 principles - tried to make the PR according to the resolution in the call.

<Detlev> ...the directional issues seemed like more complex issues - we haven't tackled time - we do nit define complex etc. We can still work on it.

<Detlev> ..we can include the timing aspect. I think this can be incorporating in another re-write.

<Rachael> scribe: Rachael

<Detlev> ...can we explain what form of dragging is in scope and what isn't? Concern is top make this easy to explain to developers.

Alastair: Trying to articulate changes needed.

What covers the kind of definitions needed.

Mike G: It is complex. It makes sense that detlev should write some new language and bring it forward.

Alastair: To be fair to the process, your original PR was made and would need review. Detlev, can you do this?

Detlev: I can do that. If we make it path based we can make a better definition for gestures that are in and those that are out.
... I can do a PR.

RESOLUTION: Leave open pending updates

Alastair: We have 15 minutes and two more items. We can likely do one more.

Understanding update: Content on Hover or Focus (Issue 605)

Alastair: 4 accepted, 1 suggested removing "Trivial" which I think we can do. It wasn't part of the change. That seems fine.
... the part of the understanding talks about a small error. I believe you are saying that the error may not be trivial but you still have issues.

RESOLUTION: Accept pull request 73 as ammended

<alastairc> q/

<alastairc> q/

Technique status check

Alastair: I just want to check in on how people are doing on various techniques. I will focus on those on the call.

<alastairc> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=2133852864

??: Are you talking about 2.1 or 2.2?

S/?? /AWK

scribe: you can look at the link and see what is imminent and what needs more work to be ready for review.

Alastair: One sheet shows the importance and one shows the assignment.

AWK: I think sometimes our first thought is to a technique that seems a good idea but ends up being very specific. In 2.0 there are a lot of general techniques becuase there are many things that can be described in a general way.
... we still have some for 2.1 like that. We should look at those first.

Alastair: I think Jake is down for a failure. I'm guessing it is general.
... Detlev, I think you were drafting a failure of character key shortcuts.

Detlev: I am not sure. I can't see the allocation. Where are the names?

<alastairc> "Failure of Success Criteria 2.1.4 due to implementing character key shortcuts that cannot be turned off or remapped"

Alastair: In the first tab but you have to expand your window to see it.

Detlev: I think I did write one that starts by making sure that no control has focus and then you press every possible character key. Its awkward. We've tried automating it through a bookmarklet but haven't had much luck with it so far. It is drafted and can be reviewed.

<alastairc> zakm, take up next item

Alastair: Please jump in even if its a general technique. We can come back to that.

WCAG 2.2 progress & updates

Alastair: Next item is progress on 2.2. Some have started. accessible authentication, focus visible have both started.

So our drafters: Jake, Rachael, David.

David: Will be able to work it over the next few weeks. There has been some discussion.

Rachael: I sent a first draft of Find the Most Important Thing out last night but I have a question about the techniques and when they are needed

Alastair: There is a deadline becuase we will need to start the first sprint.

David: If you are not the primary, can we move them forward?

Alastair: Yes, The primary is just the main POC.

<alastairc> trackbot end meeting

Summary of Action Items

Summary of Resolutions

  1. leave open pending updates
  2. Leave open pending updates.
  3. Leave open pending updates
  4. Accept pull request 73 as ammended
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/05/15 01:49:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
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/Gen: (introducing herself /Jen: (introducing herself/
Succeeded: s/metting once/meeting once/
Succeeded: s/Shawn: (rephrasing/Kunal: (rephrasing/
Succeeded: s/?? from Google/Jen from Google/
Succeeded: s/ Concurrent /Failure/
Succeeded: s/AWK:/Alastair:/
Default Present: alastairc, Chuck, stevelee, Detlev, Raf, MichaelC, johnkirkwood, Lauriat, JakeAbma, Gilbert, Arthur, david-macdonald, mbgower, Jen, Kunal, Rachael

WARNING: Replacing previous Present list. (Old list: alastairc, Chuck, stevelee, Detlev, Raf, MichaelC, johnkirkwood, Lauriat, JakeAbma, Michael, Gilbert, Arthur, david-macdonald, mbgower, Jen, Kunal, Rachael)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ alastairc, Chuck, stevelee, Detlev, Raf, MichaelC, johnkirkwood, Lauriat, JakeAbma, Gilbert, Arthur, david-macdonald, mbgower, Jen, Kunal, Rachael

Present: alastairc Chuck stevelee Detlev Raf MichaelC johnkirkwood Lauriat JakeAbma Gilbert Arthur david-macdonald mbgower Jen Kunal Rachael
Regrets: Bruce Laura
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: Rachael_
Inferring ScribeNick: Rachael_
Found Scribe: alastairc
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Scribes: Detlev, Rachael_, alastairc, mbgower, Rachael
ScribeNicks: Detlev, Rachael_, mbgower, Rachael
Found Date: 14 May 2019
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]