Accessibility Guidelines Working Group Teleconference

17 Dec 2019


alastairc, janina, Raf, Laura, Rachael, JakeAbma, bruce_bailey, Brooks, JF, AWK, Jon_avila, Chuck, mbgower, Detlev, Fazio, kirkwood
Laura, mbgower, jon_avila


<laura> Scribe: Laura

awk: last meeting of 2019.
... no meetings for the next 2 weeks.
... but you can do work.
... have a good break.

Conformance challenges review https://www.w3.org/2002/09/wbs/35422/Conformance-Challenges-FPWD/results


awk: hand the floor to Peter or Janina

peter: Think we are ready for FPWD.
... Critical to Silver. Hoping for broader feedback.

<bruce_bailey> https://raw.githubusercontent.com/w3c/wcag/master/conformance-challenges

<AWK> s/jannia/janina

JS: We have provided several responses to issues.

<bruce_bailey> oops: https://raw.githack.com/w3c/wcag/master/conformance-challenges/index.html

JS: Added a section and tweeks.
... not sure what else to do.

peter: not familiar with mechanics of survey.

<AWK> https://www.w3.org/2002/09/wbs/35422/Conformance-Challenges-FPWD/results

awk: survey replies are available.
... 2 Yes, but publish with the following changes:

3 No it's not ready, for the following reasons:

scribe: David has concerns that regarding laws and lawsuits.
... Europe is considering the EN 301-549 in legislation. Canada is enacting the C-81.
... David says This note can, without much difficulty, be interpreted as saying that WCAG is inappropriate for large commercial sites.

peter: one of the things we tried to address in 2nd paragraph of goals.

<alastairc> NB: I think David & Laura's comments came in before the very latest set of changes.

peter: SC are important but we need to recognize new challenges.
... something that we take seriously.

awk: david also says 58% of the document (2926 of 4988 words) in Sections 1-4 is about the problems of Human Testing,
... advocating for more automatable requirements (which are binary pass/fail) and less human testing. Alternatively, Section 5 from the Silver task force research is advocating for an increase in the role of non binary human testing to better address cognitive issues.
... It seems like opposite directions are proposed for Silver in the same document. (Which interestingly leaves WCAG 2.x as a moderate balance.)
... david also mentions no mention to EM.
... I don’t see that as a core issue

peter: EM seems to be about using a small sampling .
... Don’t see how sampling can help.

JF: sampling seems like the right way to go.
... what is unclear to me. Known issues. or backwards comapablity.
... what conformance model are we talking about?

peter: we are talking about the conformance model of 2.X

<AWK> In Goals: "We are publishing this document now, as a First Public Working Draft, to seek public comment and assistance in further cataloging and characterizing these challenges, so that this work can become input into the next major revision of W3C accessibility guidelines (currently in early development under the name "Silver")."

peter: 2.X doesn’t define what conforming to the standard means.

<jon_avila> Reminder: In the majority of situations, using this methodology alone does not result in WCAG 2.0 conformance claims https://www.w3.org/TR/WCAG-EM/

peter: agree that some type of sampling will be involved.

JF: doc talks about 2.X. challenges. We don’t want to break backwards compatibility.
... we can’t go backwards.

peter: goal is to inform silver and inform the interim.

<Zakim> bruce_bailey, you wanted to agree with how Peter characterized EM, so i dont understand why he doesnt like it

bruce: lack of mention of EM is a big issue.
... looking to incorporate more of EM.

Peter: second paragraph under goals.
... important document to get out there.

<Zakim> AWK, you wanted to speak to changes in WCAG 2.x conformance model

awk: we are not changing WCAG 2.x conformance model
... there are challenges though.
... this work can inform silver. and updates to EM.

JF: need to add goal is to inform a new model for silver. Not to change 2.X

<Zakim> alastairc, you wanted to speak to my comment

ac: sense we use WCAG as measuring stick as well as other tools such as sampling.
... proposed a bridging statement in my survey comments.
... wondering if that helps.

<JF> +1

peter: I like the comment

<mbgower> scribe, mbgower

<mbgower> AWK: Laura is there anything you want to call out?

<mbgower> Laura: I think the comments say it. I agree with what David said. i think Alastair said there's been an update since we commented. I believe ours was Dec 10, and it's changed since then.

<Detlev> Sorry to be late -could not join earlier

<alastairc> scribe:mbgower

Janina: I didn't realize you were surveying already

Janina There were a lot of changes to Dec 17 version.

<laura> Video of Domino's Appeal Oral Arguments

<laura> https://www.youtube.com/watch?v=jc6LG8PTvGA

Laura: Bruce asked me about law suits talking about WCAG. For sure, Domino's were citing WCAG.

<laura> https://www.adatitleiii.com/2018/10/dominos-ninth-circuit-hears-web-accessibility-appeal-argument/

Bruce: In regard to David's concerns, i was wondering if you agreed with them.

<JF> +1 to Bruce - it feels negative to WCAG in a non-helpful way

<laura> Scibe: Laura

<laura> Scribe: Laura

<bruce_bailey> scribe: laura

awk: work on tone so we are not undermining ourselves.
... reads comments
... needs some editing.
... needs to be more complete.

peter: challenges exist and are real.
... document useful going forward.
... important to connect with david.
... will go through everything in survey and address them and maybe come back in January.

<Zakim> Brooks, you wanted to ask about changing role of web production staff in conformance challenges

brooks: agree with the gist.
... changing role of web production. Big companies are trying to spend as little as they can.
... industry has changed.

awk: any more comments add to GitHub
... I will clarify my complaints.

WCAG 2.2 Confirmation before submission (2nd week). https://www.w3.org/2002/09/wbs/35422/wcag22-confirm-before-submission/results

awk: steve isn’t around this week.

AC: put this one on the back burner

jake: been through the first 2.

all the comments are the same. Why are they in the survey?

AC: thought it had been updated.

Jake: Don’t see any changes

Bruce: Think it is a new document.
... big changes from when I saw it last.

<bruce_bailey> +1 this seems like significant rewrite to me

<bruce_bailey> was still "visual affordances" last time i looked at it, sorry

RESOLUTION: leave open

WCAG 2.2 Visual indicators https://www.w3.org/2002/09/wbs/35422/Visual_indicators/results

awk: has this one changed?

Jake: Nope

AC: think it has.

3 reviews.

<jon_avila> Seems like the idea is that the user should be able to change CSS to make the changes -- so we'd have to apply to the CSS and then see if it break something.

AC: Worried it will pick up false positives.
... we are intering the next leage of difficulties.

<jon_avila> I would disagree it would generally work -- it could break visual indication of focus

AC: 2nd version borders around buttons. If it works with plug in we don’t need an SC.

AWK: It is challenging.
... everything has to be visually apparent.
... like the CSS version.
... like to figure out the core requirement so it applies to all technologies.

brooks: I like like this SC.

<jon_avila> I see a lot of input's now having a border that looks like fieldset as it's very offset from the control itself.

<jon_avila> * Laura, let me know when you want me to take over.

brooks: espeially foir flat design. Difficult to be super perscriptive.

* Anytime

<jon_avila> scribe: jon_avila

<Zakim> alastairc, you wanted to say it is important, but to convert to an SC there's a big project involved.

AlastairC: it is an important thing/issue. It is fairly common. Reasonable sized project in gathering examples to point to - to say these are good and bad and doing analysis and get a SC that only applies to the bad examples.

Jake: Have a comment about certain direction -- seems like we are going more often - we are ending up with a website that you want accessibible it looks like a plane cockpit to change color. We expect a lot of plug-ins for people who are already having a difficult time using the site.

<Brooks> +1 to Jake's concerns about requiring the use of AT/plug-ins to make visual indicators obvious to users

Jake: Just leave user with another plug-in -- we need to be cautious when using this type of alternative-- especially with CSS. Already limited to web and in this case already there -- so you don't need it right now.

<laura> s/compatibility /compatibility/

Awk: Slippery slope - rely on assistive technology in other cases -- we don't assume content will voice itself. The best result is that we don't rely on individual site authors. At what point do we stop applying that and say the author needs to do?
... Does it map to how common these tools are available? We are doing this for 1.3.5 and 1.3.6 for input purpose. Some people which you could just create straight forward semtantic content and browsers will just do what they are supposed to do.

Jake: Can you give a small response on changing style properties.

awk: that is a question we are thinking about what is needed for content to be accessible. If it's easier for author -- do we still need to specify? If it's used for technology other than the ones where it works well you have a gap for end users.
... We did not specify it works well with a pointing device like we did in 2.1 -- we just talked about keyboard access. There is an opportunity to look at these in Silver. I don't have an answer in short.

<AWK> Jon: my concern is the border - may impact visual indication of focus

<AWK> .. or things are overlapping

<AWK> ... may be an impact that an author should evaluate

AlastairC: For the visual one - more work needed to find examples. Brooks spent some time previously. Working with David would be a good next step. Giving our deadlines for 2.2 I don't think that level of project would fit in -- but this would be useful in the future as this will come up with Silver. Having that groundwork will be useful.

awk: We need to talk about with David present and make sure to point out to him we had discussion on the call -- so he can have a heads up. We need to leave open.
... Any objection to that?

<JF> +1 to leaving open

RESOLUTION: Leave open

WCAG 2.2 Custom interactions https://www.w3.org/2002/09/wbs/35422/Custom_interactions/results

AlastairC: This should be Jake's

awk: didn't get through all of survey to get to this one. We are light on reviewers. Jake and Bruce felt like the items were met.

AlastairC: My comments were mainly on concept -- defining customer interactions is difficult. It's almost reversed it to say standard is exception and then linking to well researched standard interactions across platforms. Little uncomfortable baking this into normative section because the list of standard interactions feels like it's going to date quickly.

Jake: it is exactly where we need consensus. Before we had 2 major questions - 1 is a area custom yes or no. What is custom. So we turned it around so we define standard and everything else is custom. What's left is for us to agree on custom actions.
... Started with basics of the standards and we talked about it for more than once. Question to the group - can we agree on standard list. Did I forget something in the list or do people think this is impossible. That is the most important part of the success criteria.
... Standard interactions are pretty stable in last 20 years so they probably won't change. By the time they change we will be in Silver and Silver can be extended if everything goes alright. Most are pretty standard for a long time. If we can come up with examples were they did change please let us know.

<Zakim> mbgower, you wanted to say there are challenges with the standard list in regard to component-level interaction

MikeG: Concern - the list is almost a listing of methods -- the actual thing that happens when you tab

<Zakim> Brooks, you wanted to provide an example of where intructions are needed (ARIA widgets), because the interaction pattern varies from what many users expect from native HTML

MikeG: Hard to see hard to fail if you don't reference something more comprehensive than this.

<laura> s/intering the next leage /entering the next league /

Brooks: Another SC that I like. How do you get someone to adopt new interaction pattern. Such as in addition to tab, use arrow keys and home and end keys. The enhanced is fantastic to allow keyboard user to interact- but they need to know about these changes. How do we present instructions. Do we make them persistent, do we put them in modal?

<Zakim> alastairc, you wanted to ask if it is custom 'interactions', or standard interactions with custom features?

Brooks: Additional thought in how instructions appear to user.

<laura> s/like like /like /

AlastairC: Some use a standard to a customer interaction. For example, a swipe left on an email to delete it -- I thought was the custom thing we were looking for. Defining standard is a red herring. The problem is unexpected features whether or not you were using a custom interaction.

<laura> s/espeially foir flat design /especially for flat design /

Jake: not sure what you are after.

<laura> s/perscriptive /prescriptive /

AlastairC: Standard interaction is fine -- but what if it's a standard interaction with unexpected outcome. What if you swipe to open a menu. It's not expected.

<AWK> Perhaps Alastair means "Functionality is carried out using standard interactions or provides instructions for the user"

<Detlev> Alastair has a good point

<laura> s/* Anytime //

Jake: This is about interaction itself - if you swipe left and something happens and one thing happens.
... For example, if you have swipe left and one thing happens and it's consistent that's fine -- that is the outcome. The moment swiping left 60% does A and 80% does B and 100% does C then your swipe has multiple actions underneath due to swipe. Then it's custom.

<mbgower> In the context of using a book emulator, swiping left advances you to the next page. That's an expected/established interaction. But swipe left in an email inbox might mark the item 'read' or delete it, or even open it.

Jake: The moment you start combing things it becomes custom. We explained in examples.
... Some new definition - for example for custom interactions. Use "combined".

<mbgower> They are all using swipe left, but the results can be different. So just listing 'swipe left' does not establish an actual interaction.

AlastairC: I see that for customized swipe. It's more of a case for things like carousel that fills only part of screen -- how are you supposed to know to swipe?

<Zakim> JF, you wanted to ask about "interactions" versus outcomes

JohnF: Getting a little concerned around notion of interaction and swiping. For someone with mobility impairment they may not swipe.
... In some ways you are talking about ARIA roles. Can have a role of slider -- the interaction can be horizontal or vertical. For keyboard only users will have same interaction. That feels like opposite of what you are saying.
... Your point on custom -- I see that - I haven't seen that in real world. Do we have examples of new interaction patterns that need to be explained because otherwise it's a blackbox.

Jake: This isn't about roles. All interactions -- all keyboard gestures - they use a pretty scoped set of keyboard actions and you can apply to WAI ARIA components. It's more about if you implement not tabbing but you have to use tabbing + character d or f before it moves focus it's custom.

<Brooks> I think context matters, in terms of determining when instructions are needed to make expectations clear to users. Arrow keystrokes are part of standard interaction patterns (cycling through a dropdown menu in a select element). But, arrow key navigation for tab widgets is not well-known to users. Does a user, in a given context, have a clear expectation of how to interact with the controls?

Jake: For keyboard would be fine with WAI ARIA. Custom swipe is one of the reasons why this popped up.

<alastairc> It seems the focus of the SC has changed from: Unexpected interactions need instructions, to non-standed 'commands' need instuctions, which is a narrower set of scenarios.

Jake: If you have a list of notes or emails or other list of action - actions available swipe left - archive, respond and then if you go all the way the option you swipe will be deleted or archived. There are multiple available under one swipe to the left. Those are the ones to be documented or instructions available.
... We have a whole list of instructions on how you could deal with that. We provide at least 15 ways from an icon to a help file to a tooltip.
... Specifically when you combine more than one.

<alastairc> q/

JohnF: This is all in the context of custom components?
... surfacing that idea - feels like this comes into play with custom or components.

Jake: Or overriding the standard.

JohnF: We can't be depending on one mode of input. Interactions is a red herring. It's a problem. Wonder if we got that right.

<Zakim> AWK, you wanted to ask whether WCAG is the right place for the interactions to be defined (chair hat off!)

awk: What I worry about with this -- if we are defining standard interactions -- that is a multi-year standards process on it's own. I feel like our chances of success for 2.2 are pretty small. We need to figure out a way around that.
... What I put in up above -- was basically - if we have an SC that was saying where you defined -- thinking about roles -- but Jake you are saying your note -- where a role is defined it either uses that interaction model that expected for the platform or it is displayed on.
... In the case of web content on an Alexa TV - there is no tab key - there needs flexibility in terms of what keys are platform specific interaction is.

AlastairC: It is is now focused on a more non-standard interaction - then you need to provide instructions. Seems like a sub-set of where it was before.

Alastair: A custom interaction includes simple interactions but may have unexpected results like swiping in from right for menu. Another example might be press J in a twitter stream to go previous or next. Those are standard controls with unexpected outcomes.

Jake: That is also a custom interaction if it's not defined in the list.
... Not sure what outcome is define by a swipe.
... If that swipe does more than one thing then it's custom.

AlastairC: Standard pointer gestures - if something uses a standard swipe - and outcome is not what you expect - if you swipe to the right goes forward in history.

Jake: For example, if you swipe in email and something happens like archiving without you knowing.
... Let's go 2 steps back. The intent - discoverability of non-standard interactions/gestures and also preventing the user know how to return or get back what they have done.
... Trying to cover those 2 situations
... Everything comes down to what is custom - and that is not possible to define. turn around like we did with input purpose. Last Thursday I had a list of somewhere from Wikipedia from hundreds of keyboard strokes. We can agree on standard list unless it's too big not not stable.
... Same for touch, swipe, pointer gestures.

<Brooks> Affordances give users a understanding of what the standard interaction pattern is for a control. That SC ties closely into this Instructions for Custom Interactions SC. It's the main reason why you want to give sighted users a clear understanding of what a widget's role is - what does it do, and how do I interact with it?

AlastairC: preference is to not list.

Jake: if we can't get list it will be hard. Andrew's suggestion is to point to another standard like WAI ARIA. Not sure if we want to point people to other standards.

awk: What people define as standard changes over time. It has be defined somewhere as standard.
... On iOS they would describe left on a row of email would be standard.

Jake: If they have defined it with instructions then it's standard.
... We only define the standard standards as we do with other places.

<alastairc> E.g. iOS has a stndard 'flick' gesture, which is apparently different from swipe?? https://developer.apple.com/design/human-interface-guidelines/ios/user-interaction/gestures/

Jake: Pressing enter or return is standard. It would be good to come up with concrete examples. Maybe look at list and add and delete some.

awk: What do others think about coming up with a standard list?

JohnF: ARIA roles might be a starting place. Not sure if it's complete.

Jake: All keystrokes are there widget by widget and role by role.

AlastairC: Could we move it up a level - rather than interaction - if there is a way to define the function rather than interaction.

Jake: Do we have to come up with a list of functions?
... Is it a bad idea to only focus on list and ask people to go through it to see if we need to add another or delete?
... Need to find example of where something won't work - maybe we need to go in a different direction. I did not hear on concrete examples except one from MikeG.
... Tap - example - if it activates something - is that a custom interaction?
... We define tab does this and this and this - goes to the next and we put it in the list and it's standard. Otherwise you need to document

<scribe> scribe:jon_avila

Brooks: We have 20 years of history on native HTML elements and the expectations. A lot of htis is water under the bridge. A lot of this is about the new things such as Touch. We don't have participation from folks. It's fair enough to look at what has been done in the past and document those standard interactions and paltforms and what has been done and how long. Start with what has been established.

<Zakim> mbgower, you wanted to say IBM just references ARIA APG

MikeG: Anyone that is reporting under revised 508. 602.2 already covers keyboard documentation. It's not impossible to crack - but each org comes up with it's own way. If you are not following the interaction guide then you have to document.
... What is obvious to one user is different - what is expected interaction -- really changes espeically when you bring in cognitive decision. The friction is there. I don't see folks not wanting to provide instructions.

awk: This was just added this week. We are looking for examples and counter examples. We need to determine if we can bring in part of an external standard or is some other approach possible. There is a problem to solve here even if there is concerns of the viability of different solution until we get more clarity.

RESOLUTION: Leave open

CFC for Focus Styles

AlastairC: For focused Enhanced - the crux - Jake was thinking it should have a fixed sized focus indicator -- but for the moment it's proportional indicator. I could scenario where one would be other. Proportional should be easier to test. Just wanted to get Jake's temperature.

<alastairc> i think this is the example referenced: https://raw.githubusercontent.com/w3c/wcag/wcag22-focus-visible-enhanced/understanding/22/img/focus-indicator-icon.png

Jake: You have a menu - on a left side - an 8 pixel bar to indicate which one is hovered or focused or active. You had 2 examples in your documentation. Imagine you have a list of links which have a focus indicator on the left side - 8 pixel. 8 pixels wide and 30 high. That same link goes to block. 320 pixels wide and 30 pixels high. That now has to have 640 pixel area. So your 8 pixel bar must become 21 pixels.
... So know you have a bigger touch target on mobile -- but the same indicator must be 3 times larger on phone because of the calculation. When the target gets bigger the indicator must be bigger. That means you can't use the same indicator after different different breakpoints.
... Doesn't make sense that it's not fine in certain situations.

<laura> Bye all. Happy holidays.

awk: Have a great holiday. Next time we talk will be in 2020.

<Detlev> bye

<Rachael> Happy holidays. See you in the new year.

Happy holidays!

trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. leave open
  2. Leave open
  3. Leave open
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/12/17 18:02:34 $

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)

FAILED: s/jannia/janina/
Succeeded: s/suvery/survey/
Succeeded: s/Peter: I didn't/Janina: I didn't/
Succeeded: s/Peter: There/Janina There/
Succeeded: s/big changes fro when I seen it last/big changes from when I saw it last/
Succeeded: s/addfress in 2nd paragrahp /address in 2nd paragraph /
Succeeded: s/we nee to recogn isew /we need to recognize new /
FAILED: s/comapablity /compatibility/
Succeeded: s/whart /what /
Succeeded: s/compatablity/compatibility/
Succeeded: s/Dvaid /David /
Succeeded: s/measureing /measuring /
Succeeded: s/Jannia/Janina/
Succeeded: s/familar /familiar /
Succeeded: s/+1 to leave open//
Succeeded: s/comapablity/compatibility/
Succeeded: s/paragrah /paragraph /
Succeeded: s/everyting /everything /
Succeeded: s/been thought /been through /
FAILED: s/intering the next leage  /entering the next league /
Succeeded: s/apparrent/apparent/
Succeeded: s/appies /applies /
FAILED: s/like like  /like  /
FAILED: s/espeially foir flat design /especially for flat design /
FAILED: s/perscriptive /prescriptive /
FAILED: s/* Anytime //
Succeeded: s/letter/level/
Succeeded: s/customer interaction/custom interaction/
Default Present: alastairc, janina, Raf, Laura, Rachael, JakeAbma, bruce_bailey, Brooks, JF, AWK, Jon_avila, Chuck, mbgower, Detlev, Fazio, kirkwood
Present: alastairc janina Raf Laura Rachael JakeAbma bruce_bailey Brooks JF AWK Jon_avila Chuck mbgower Detlev Fazio kirkwood
Found Scribe: Laura
Inferring ScribeNick: laura
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Found Scribe: Laura
Found Scribe: laura
Inferring ScribeNick: laura
Found Scribe: jon_avila
Inferring ScribeNick: jon_avila
Found Scribe: jon_avila
Inferring ScribeNick: jon_avila
Scribes: Laura, mbgower, jon_avila
ScribeNicks: laura, mbgower, jon_avila
Found Date: 17 Dec 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

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]