<laura> Scribe: Laura
awk: last meeting of 2019.
... no meetings for the next 2 weeks.
... but you can do work.
... have a good break.
<AWK> +AWK
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.
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
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
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
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
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]
