<Chuck> Zakum, start meeting: AGWG-2020-05-19
<AWK> +AWK
<Chuck> Zakum, start meeting: AGWG-2020-05-19
<alastairc> meeting: AG meeting
<AWK> Scribe: AWK
Chuck: (showing changes)
... think it is editorial for defining requirements
<Detlev> Can't find the Agenda with meeting lgon details...
Chuck: any questions/issues, let us know
Wilco: minor thing that a best practice can't be called an "accessibility requirement" so we want to fix that with this
CHuck: expect a CFC ASAP
Chuck: Most responses are supportive, some want changes
Rachael: couple things
<scribe> ... closed survey early
UNKNOWN_SPEAKER: the intent was
to close before the meeting so COGA could respond
... we did do that
... reviewed all comments and made changes
<Rachael> https://github.com/w3c/coga/pull/114/files
UNKNOWN_SPEAKER: if want to see the diff see link above
Chuck: my changes were
syntactical only
... otherwise support it
... Most people feel this document helps people
... (reviewing survey responses)
Rachael: The policy section was
raised as a concern
... title has changed for that section
Chuck: second question -
substantially supporting comments
... Third question - more people suggested changes to the
structure
... Laura suggested a title change for the policy section
Rachael: new title is:
<Rachael> revised title: Considerations for Uptake in Different Contexts and Policies
<alastairc> Is there a URL for the new version?
<laura> +1
(reviewing other comments)
Rachael: Example section has "do"
and "don't" examples
... Q4 in survey - clear and useful, generally yes responses
with some suggestions
<alastairc> Looks like some of the examples might need slight updates, e.g. "Don't: Dense text, with little white space...". Should start with "Use" or something similar.
Rachael: reviewed for causality (author vs content) and clarified
<mbgower> +1
<stevelee> +1
Rachael: reviewing changes (pasting into IRC)
<Rachael> David's recommendation: Change: "People with cognitive and learning disabilities may not be able to effectively use web content because of the design and content choices of the author." to "Design and content choices can impact the content in ways that make it difficult or impossible for some users with cognitive and learning disabilities to use this content."
<Rachael> Changed this to "Poor design, structure and language choices can make content inaccessible to people with learning disabilities.
We use the serial comma in our docs, FYI
<Rachael> People with cognitive and learning disabilities may not be able to effectively use web content because of the design and content choices of the author.
<Rachael> https://github.com/w3c/coga/pull/114/files
<Rachael> 2. Was Not Changed: It gives advice on how to make content usable for people with learning and cognitive disabilities.
Rachael: Other suggestion was to link to github and I don't think that is appropriate
MG: suggesting removing "poor" in sentence above
<stevelee> diffs - https://github.com/w3c/coga/pull/114/files#diff-09661ca8d0fac0a5c28242b9335053f5L146
<stevelee> inappropriate?
Rachael: will take recommendation to remove word
<alastairc> There is an assumed lens of 'from a COGA point of view', which is what makes it poor.
Chuck: Q5
... 3 yes/4 no
<alastairc> Relationship with WCAG
<Rachael> https://raw.githack.com/w3c/coga/responces-to-cfc-april-2020/content-usable/index.html#abstract
<Chuck> awk: What has changed since first reviewed that would change that?
<Rachael> https://raw.githack.com/w3c/coga/responces-to-cfc-april-2020/content-usable/index.html#introduction
<Chuck> rachael: new abstract, added text. Added clarification text to the design guide in case the abstract wasn't read. I'll provide design guide intro.
<Chuck> Rachael: We also re-ordered doc, if you start at the top looks less like WCAG.
<Chuck> awk: loading link...
<Chuck> awk: The concern I have is wrapped up with the policy guidance concern as well, which I have to see what the changes are that have been made.
<Chuck> awk: I'm concerned that we work debate, argue around normative language for the sc, and that's what makes them as good as they are.
<Chuck> awk: Even then they aren't perfect.
<Chuck> awk: I want to make sure we avoid a suplimentary document that gets positioned as "it's just as good". We want to do that, but we don't want to have things that are in here as required for all web content.
<JF> +1 to AWK
<KimD_> +1
<Chuck> awk: that's what I'm concerned about making sure we don't have that happen.
<Chuck> awk: Now that there's changes, I want to review. I can't do that quickly while I'm scribing.
<Chuck> awk: It's a complicated question. I need an opportunity to review this document related to those points.
<chrisloiselle> AWK, I can scribe whenever you need to review if you'd like , if it helps. No worries if not.
Chuck: David also said no to Q5
Rachael: we looked at DM's
comments
... modifed abstract
... removed table for policy makers
Rachael: Links to GitHub - the WG
should discuss
... COGA feels that the content of the github links is
useful
... What does WG think?
... What are people's concerns with Appendix D?
<Zakim> alastairc, you wanted to ask about terms like supplementary / extension
AC: not sure how the term
extension is being used?
... we should be clear that this was the supplementary guidance
discussed as we approached WCAG 2.1
... recommending use of "supplementary guidance"
JF: appendix D - types of notes
coming out of WAI like MAUR and others, none link back to
earlier research
... perhaps stored in a parallel location instead of this
doc?
+1 to JF on parallel location
Chuck: Is that your primary concern with Appendix D?
<alastairc> Probably best in the gap analysis doc?
Rachael: Would you be ok with a note in the appendix and linking to a different location?
JF: yes
<Chuck> awk: I agree, that would be great, because the other issue, these other things can change and evolve, nice to have a note that "this is the stable advice at this moment, here's the link"
<JF> +1, as well as noting that we also have updated Notes in the past (CAPTCHA)
<Chuck> awk: Obviously if issue 55 or 31 or pr 108 changes, then our conclusions might change, but there's tracking. I like keeping it separate and making it less densen.
Rachael: will implement that change
Chuck: Other issues/concerns?
<stevelee> +1 wiki
<Rachael> Current text: People with cognitive disabilities often use add-ons or extensions as assistive technology.
Rachael: DM suggested using "may"
instead of "often" and we didn't make that change.
... didn't make that change
Chuck: reviewing Q6
Patrick suggests clarifying that it is on top of WCAG
scribe: Andrew has problems with
the policy appendix
... bruce does as well
<Chuck> David M: think we need to: 1) Make edits listed above. 2) provide clear language that states the relationship with WCAG up front that it doesn't add to the requirements WCAG 3) Remove links to WCAG Github issues and pull requests 4) remove or amend the table which says all the previously unaccepted WCAG SCs meet all the SC Acceptance criteria 5) Change titles of "Failure Example" to "Unsuccessful Example"
Rachael: made a bunch of changes,
people still need to review changes made
... suggest new survey to look at changes
... perhaps as a CFC?
AC: I think that it would be useful to do a simpler survey first
<PascalWentz> @Rachael a suggestion for the Text in the Appendix D: Some People with cognitive disabilities use add-ons or extensions as assistive technology.
Chuck: think resolution is to have a simpler survey
RESOLUTION: Chairs will create a simpler survey to review changes
AC: re: Andrew's comment on the
radio choice, temporarily is part of it
... I assumed that if it is a failure then sticky head/foot
can't be used
... another newer CSS attribute called scrollPadding that may
help
... seems that there isn't a robust solution to this
... may have missed the boat in trying to forbid them
Chuck (as just a guy): After hearing the conversation agrees with this not being a failure of 2.4.7
Chuck (as a chair): anyone think it is a failure?
Brooks: last week mentioned that sticky footer/content might be a failure of focus order
<alastairc> Especially interested in Gundula, Stephan or Oliver who answered last week.
Brooks: feels a little strange to make excuses for a design pattern that is unequal for keyboard and mouse users
<KimD_> +1 to Brooks
AC: there are scenarios where
having the sticky content can be beneficial
... for those who think it should be a failure, what is our
advice?
Brooks: we should advise content authors to provide users with a choice
AC: In reflow we have an advisory
technique for this
... we could do similarly
... for this
<chrisloiselle> scribe:ChrisLoiselle
:)
Chuck: For the advisory
technique, did that make it a outright failure? Alastair: No,
not a failure. The experience would impact "X" users...
... One is to craft advisory technique for sticky headers and
footers. The other question is do we call it a failure or not
call it a failure?
<Detlev> Jon Avila seemed to lean towards failure
Stefan: Floating footers, sticky on bottom of window was also talked to. We changed these floating elements to fixed regions and do not allow for overlapping.
<KimD_> +1
Footers had large amount of screen real estate and focus behind these sticky footers confused users on focus. I wouldn't recommend allowing for those type of things.
DavidM: Two scenarios. Scrolling into view and hidden behind sticky header/footer. Second is a failure.
Perhaps introducing new SC to take up concerns on this particular example vs. fitting into 2.4.7
Chuck: Plus one to DavidM. Square peg in a round hole. Cleaner to make SC to talk to this example.
JF: How much of this should fall on user agents ?
<Zakim> Brooks, you wanted to say it gets tricky with a two column layout, when moving focus forward through the focus order to the top of the second column, which is behind a sticky
Brooks: Tabbing to a second column, focus is lost behind sticky header. Scrolling backwards , back up to expose the focus indicator. Is that on user to understand?
<KimD_> +1 to Brooks
<Zakim> alastairc, you wanted to talk about CSS Bug
<alastairc> https://github.com/w3c/csswg-drafts/issues/5066
Alastair: To the user agent issue, it is a good question. The CSS bug talks to the user agent issue as it doesn't appear to note how browsers use this correctly.
Its not defined entirely. So whether that talks authoring vs. user agent or something the user needs to adapt to.
<KimD_> Isn't that the goal of an "evergreen" standard?
Chuck: The cleanest approach
appears to crafting a new SC , as the design pattern has risen
after 2.4.7 was written.
... to Kim, can you confirm what evergreen means?
DavidM: We wanted to create success criteria that had broad language and could be testable. I.e. keyboard accessible. Intention was to write principles that would stand over time, 10 plus years, adding 2.x to that overtime to fill in gaps.
The SC doesn't say you can't take an action to get visible focus...
JF: I think investigating a new SC is worthwhile , but still in investigating stages. +1 to investigating. Chuck: I agree, first step is investigating.
<david-macdonald> +1
<Ryladog> +1
<laura> +1
<Brooks> +1
Chuck: Does our team want to investigate a new SC ?
<kirkwood> +1
<Detlev> +1
<Zakim> mbgower, you wanted to say add 'visible in the viewport' as fourth bullet?
<mbgower> Present in viewport: The item with focus is visible in the user's current...
<alastairc> FPWD of this SC: https://www.w3.org/TR/WCAG22/#focus-visible-enhanced
<Detlev> "present in viewport but UNDER other content?
MichaelG: To further what Alastair was stating, there are three bullets that talk to visible enhanced. Perhaps we add more into the context of that SC.
Detlev: Question to Michael, do you mean in the viewport in the visible area of browser? Or would you outlaw sticky headers?
MichaelG: Sticky header would be obscuring the content.
<Zakim> alastairc, you wanted to check interprestation of 2.1
MichaelG: We'd want to make sure viewport is a defined term.
Alastair: Temporarily obscured element is an issue, but we haven't answered whether it fails 2.4.7
<Chuck> q/
<Zakim> JF, you wanted to note that this type of debate is why we need to step back and have more discussion...
<Chuck> straw poll: Is a field in focus behind a sticky header or footer a violation of 2.4.7?
JF: I think Detlev and MichaelG's conversation points to us pointing this conversation on the shelf for creating a new SC, perhaps a 2.3 issue we can talk to later.
<Ryladog> +1
<KimD_> +1 yes, it's a voilation
<Detlev> -1
<Fazio> 0
<OmarBonilla> +1
<mbgower> -1
<Brooks> +1
<alastairc> -1 (not fail)
<david-macdonald> -1
<JakeAbma> -1
AWK: -1
<GN015> +1, it is a violation
<Shanew> -1
<JF> -1, because of "has a mode of operation"
<kirkwood> -1
<laura> 0
<JF> Current Text: "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible."
<PascalWentz> +1
From Understanding 2.4.7: Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
<Stefan> -1
<KimD_> +1 to Brooks
Brooks: A lot of people do believe this is a failure , so may not be a point to vote.
<Ryladog> +1 to Brooks
<david-macdonald> https://www.davidmacd.com/blog/sighted-keyboard-only-user.html
Chuck and Alastair: How do we move forward on if it is a failure? We need to discuss further.
<OmarBonilla> +1 as well Brooks
<Stefan> +1 to poll
<Ryladog> Like...The default view
<Zakim> mbgower, you wanted to say I'd like a poll of who thinks this SHOULD be a failure?
MichaelG: Behavior and what Alastair talked to , focus becomes invisible , because it is hidden.
<Detlev> +1 to Mike
<Ryladog> +1
<Chuck> new poll: Should this behavior be a failure of 2.4.7?
<kirkwood> +1
<Ryladog> +1
<Chuck> new poll: Should this be a failure?
<Stefan> +1
<mbgower> +1
<KimD_> +1
<JakeAbma> +1
<Chuck> +1
<OmarBonilla> +1
<Detlev> +1
<Ryladog> +1
<Brooks> +1
<kirkwood> +1
+1
<Rachael> +1
<Shanew> +1
<alastairc> +1 assuming we can show it is feasible, which we can with wider review of new SC.
<Francis_Storr> +1
<GN015> +1
<JF> +1 to "it MIGHT be an author faliure, but it is not currently covered by 2.4.7
<PascalWentz> +1
<Detlev> +1
JF: I think that we need to investigate this further.
Detlev: I think the browser, Chrome for example, may move focus up, so is it the browser behavior? Is it an author or the browser?
<mbgower> +1 I agree to more investigation, but I don't think that should stop us from pursuing under 2.4.11 Focus Visible (Enhanced)
JF: I think the resolution is that we need to talk about this more, perhaps later on.
Chuck: does everyone agree with this as the resolution?
<JF> +.75
<david-macdonald> +1
<Brooks> +1
<GN015> -1, I rather see it as a requirement on its own, if clarifying in 2.4.7 Understanding is not sufficient.
<Stefan> -1 mee too
<Detlev> -1 might overload Focus Visible
<KimD_> +0 because I think it's already a failure under 2.4.7
<JF> +1 to Detlev
Detlev: I wouldn't want the new focus visible enhanced to be delayed. I'd rather a new SC that talks to this specfically.
Chuck: I'd like to respond to the issue. In that we don't have consensus and we are looking into this more in detail.
<JF> +1 to Chuck
DavidM: I've never seen an interpretation that something that temporarily obscuring causes a failure. I know that when 2.4.7 was written, that sticky headers were not present.
<mbgower> +1 to chuck
<AWK> It would probably be helpful to have people answer on the survey to support whatever conclusion. Right now there are 4 responses that say not a failure
<JF> The ADA *DOESN'T* cover the web
<Fazio> +1 Kim
<Zakim> alastairc, you wanted to ask if modals typically fail focus visible, or focus order?
Kim: Just because 2.4.7 doesn't have sticky headers at time of publishing , I think they may be covered.
Alastair: I think controls do have an indicator, it is just not in view at moment, thats the issue.
JF: To Kim, the ADA doesn't cover the web , technically. ADA was written before the web. DOJ suggests that ADA applies to Web. Similar situation on use case. There's nothing that talks to specific use case.
<AWK> The ADA does cover public accommodations and the current case history suggests that the prevailing view is that the web is a public accommodation in most cases.
<kirkwood> we have a much greater variety screen sizes these days as well
<Fazio> is it implied?
<Fazio> courts recognize implied intent
<JF> +1 to that Chuck
Chuck, can you repeat that
?
<KimD_> +1 to AWK - not really an answer
<JF> +1 to avoiding crickets
<kirkwood> +1
Chuck: An answer to the question is beneficial, even if we don't have consensus.
Gundula: talks to keyboard use and current wording may be misunderstood. I.e. on keypress vs. on presence of keyboard.
Chuck: I.e. attached / via bluetooth for example.
<mbgower> gower
Alastair: I think it was an addition to understanding document.
<alastairc> https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html
AWK: In the intent? Where exactly ?
<Zakim> alastairc, you wanted to say that keyboard should not trigger focus indicator
Alastair: I don't think we want to suggest that focus indicator is reliant on keyboard. The user would need to "tab" . So I'm not sure what mode of operation came from. Edge cases may have come into perspective.
Stefan: If you attach a bluetooth keyboard to android device, it shows focus. It could vary by OS, or browsers. It will be adapted to non web , especially in Europe. So when attaching a keyboard, it is visible.
AWK: I think the reason we had this language is that someone is using a mouse and keyboard focus is not present. The keyboard focus indicator may not be shown when focus is set by the mouse. The focus would need to be shown when the mode of operation is such that the user is using the keyboard to move the focus..
Chuck: To Gundula , does this conversation influence your concerns? Gundula: I don't think it covers everything.
Alastair: We wouldn't want it to state whenever a keyboard is attached that visible indicator is present. I'm not sure how you'd want this to be stated.
Gundula: I don't want authors to turn this off with the user to turn it on again
Katie: I think you may be looking at this from a closed system. There are requirements for audio for example that audio starts playing. Maybe that is what you mean?
Gundula: I haven't seen someone who hasn't been on computer without a keyboard.
Pascal: Does this only apply to closed computer technology? I.e. headphone plugged into a PC , closed functionality vs. open?
Katie: That was what I was referencing as well.
AWK: The WCAG SC that talk to keyboard, talk to keyboard interface. Web content / authoring content can't check for keyboard plugged in. The UI needs to respond to the keyboard. Focus is on window ,until user presses tab once. I don't think we'd talk to keyboard being plugged in...
When pages load, it is not visible, unless someone explicitly sets focus beforehand.
Alastair: We are talking to adding a paragraph for understanding document for mode of operation text.
It is a clarification of the wording.
Does anyone object to the clarification wording / sentence in understanding document?
<Chuck> any objections to adding this clarification sentence to the understanding document: “Mode of operation”, accounts for platforms which may not always show a focus indicator, or only show the focus indicator when the keyboard is used. User agents may optimise when the focus indicator is shown, such as only showing it when a keyboard is used.
Chuck: Gundula, do you have any feedback>
Gundula: talks to text of "connected"
<KimD_> Noting we're at time and people have dropped off - let's continue
Alastair: I think we need to talk to this later...no resolution.
RESOLUTION: Leave open
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/approriate/appropriate/ Succeeded: s/abo e/above/ Succeeded: s/bruce: think/David M: think/ Succeeded: s/failure/failure?/ Succeeded: s/taht/that/ Succeeded: s/The keyboard focus indicator may not show focus. So, to use keyboard to set focus, the focus needs to show (made visible)/The keyboard focus indicator may not be shown when focus is set by the mouse. The focus would need to be shown when the mode of operation is such that the user is using the keyboard to move the focus./ Present: Chuck alastairc Shanew Rachael Fazio PascalWentz Laura chrisloiselle Brooks JF Francis_Storr stevelee Nicaise JakeAbma kirkwood mbgower Glenda GN015 Stefan Jennie david-macdonald Katie_Haritos-Shea OmarBonilla WARNING: Replacing previous Regrets list. (Old list: Bruce_Bailey, Rafal_Charlampowicz) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Charles, Hall Regrets: Charles Hall JustineP Found Scribe: AWK Inferring ScribeNick: AWK Found Scribe: ChrisLoiselle Inferring ScribeNick: chrisloiselle Scribes: AWK, ChrisLoiselle ScribeNicks: AWK, chrisloiselle WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]