<Detlev> scribe: Detlev
<Chuck> I'll be backup
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.
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.
Alastair: We had a very large survey and unfortunately not too many of the questions were easy. We organized to prioritize the techniques.
<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
<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.
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.
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/
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.
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
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]