AG teleconf -- 12 Jan 2021

<laura> Scribe: Laura

<alastairc> https://www.w3.org/WAI/GL/wiki/Scribe_List

AC: anyone want to introduce themselves?

Ben: I have presented on silver. Looking forward to working with everyone.

Focus visible updates https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates2/results

Hidden controls update (question 1 only) https://www.w3.org/2002/09/wbs/35422/hidden-controls-12-2020/

<alastairc> https://www.w3.org/2002/09/wbs/35422/hidden-controls-12-2020/results

<AWK> +AWK

AC: this is a roll over. Have talked about it before.

<alastairc> New version: https://raw.githack.com/w3c/wcag/master/understanding/22/visible-controls.html

AC: are we happy with the new version?
... or do we defer to silver?
... a lot of previous issues
... is Stefan on the call?
... no.
... good requirement. But if it doesn't fit into the 2.x structure we can use silver instead.
... Stefan suggestion was: Success Criterion 3.2.7 Visible User Interface Components (Level AA)

Information needed to identify user interface components is visible without requiring pointer hover or keyboard focus, ...Exceptions:

- The information needed to identify the user interface components is available through an equivalent control that is visible on the same page.

scribe: Confusing because of being superfluous.

RM: not superfluous

GN: confusion with process and step
... different situations.
... afraid people may not understand it.

AC: should be a pass. Not sure what the problem is,
... Interaction is very similar.

GN: different between having a different page or focus.

JA: just saw an example. Icon and text. If hover read more link. Is that caught by this?

AC: that would be a gray area.
... can depend on how they look.

JA: I think so. Not a lot a visual cues.

AC: information inner to identify area. Don't have an answer

DM: could have an example.
... if .no other indication that would be a failure.

<mbgower> Yes, that's my understanding too.

DM: we wanted the language to be a little squishy.

AC: if was a multi-step process that would be okay.

Dm: agree

AC: Some advantages to removing it would incease the scope
... Andrew was talking about cards.
... think yes it would be okay

MG: If doesn't require focus.
... model works pretty well.
... multiple ways of meeting this.
... check the last bullet.

DM: I agree. We also have. 3.3.2.
... could have an exception.

<jon_avila> so it sounds like having controls appear on click is acceptable - as long as it looks clickable?

<GN015> I understand these are typical context menu features. So I suggest to except context menu indicator and context menu functionality, such that these are visible on hovering/focusing the element they belong to (Card, email, other complex UI element).

Chuck: much like a dropdown component.
... would meet this criteria.

Awk: if you have a set of cards and the other controls are available that may work.
... with sets of things that have built in functionality. You can tab or arrow.
... are Both patterns okay?

AC: good question.

<david-macdonald> I can answer that

Jemma: question on keyboard nav. What is the logic for this?
... "not modified by the author..." sentiment is not clear.

DM: exception for skip links.
... we don't want to fail that.
... emerging patterns for keyboard nav. It wouldn't encroach on that.

GN: first email now cards.
... suggest exempt context menu functionality.

AC: not sure about hovering. Tricky situation.

<david-macdonald> I might be able to answer that ... a context menu is right click or a keyboard... so its not covered in SC

AC: COGA said hovering causes a dead end for some people
... screen shots are useful

<Rachael> https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit

<Rachael> Bottom of the document

<Jemma> my feedback is that this SC is a bit broad with attempt to cover everything. May need to narrow the scope ?

JA: how do you something is clickable?

<Wilco> +1, for a thing to look interactive should be key. Clickable shouldn't be an "out"

AC: It has an identification aspect

<Jemma> my two concerns are 1) The control is provided specifically to enhance the experience for keyboard navigation; and 2)The visibility of the control is determined by the user agent and not modified by the author;

<stevelee> this is the user need I believe is behind it - and the pattern - https://w3c.github.io/coga/content-usable/#user-need-3

AC: Examples: https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit

GN: seems to be related to WYSIWYG editors

AC: not the case on square space example.
... we are not concerned with tab order for this SC.
... some aspects to make it coherent.

<Jemma> may be it is mouse navigation, not keyboard navigation since keyboard navigation will include tab orders?

<Zakim> mbgower, you wanted to say that mobile is a good way to think of this

DM: word press example is what we are trying to solve. Looking for stuff by hovering is hard.

<Jemma> pointer user makes sense.

Mg: main intent is for pointer user

<JF> +1 to Mike

Mg: had to include keyboard.

<Jemma> may be the word is "focusable" , not keyboard navigation?

Mg: mobile devices must have this.

<alastairc> JF - Mike was talking about general usage, not an accessibility thing

Mg: best example on zoom calls. Can't see controls until you hover over it.

<kirkwood> MG good point to the Zoom example

<Zakim> Rachael, you wanted to say that this is much more about sighted mouse users (both low vision and cognitive)

<kirkwood> +1 MG

RM: refocus on the COGA need.

<Jemma> +1 RM

RM: goal is to give people an indication so it is not a barrier.

<kirkwood> +1

<Jemma> if it is not about keyboard accessibility, it would be better not to have the saying in the spec because it will confuse lots of developers.

<Ryladog> keyboard is addressed in other SCs

GN: examples need to show you can interact with it.

DM: context menu is out of scope.

<mbgower> i understand what Gundula is concerned about.

DM: would like to cover it.

JF: agree pointer user is the main usecase

<mbgower> My point was that you can't design with the assumption that mobile users use keyboard.

<Jemma> +1 to JF

JF: but careful about keyboards and mobile.

<Zakim> JF, you wanted to commnet on Mikes reference to keyboards and mobile

<Chuck> +1 to agree that it "can"

AC: for a card scenario, I think the answer is yes
... on hover it would presumably pass

DM: I would like to provide instructions or have a setting.

AC: tricky.
... discoverability is not an issue for those 2 cases.

Dm: like youtube and autoplay

<mbgower> The youtube full screen example would seem to meet "essential" to me.

Dm: I will generally pass those. Depends on intention.

JA: seems contrary to exempt.

AC: Oliver had a couple of comments.
... "The SC should be based on general principles, without direct reference to hardware."
... that would undermine the intention of the SC.

<Zakim> mbgower, you wanted to say full screen mode exemption?

AC: also talked about exception 3 and the use of a user agent artifact .

Mg: for Netflix example, could have exemption.

<Ryladog> Back button?

jennie: simple control would be helpful for some people.

SH: notion of possible actions
... make sure possible actions are recognizable and identifiable without hover or focus.
... possible actions need to be identifiable.

<sarahhorton> https://docs.google.com/document/d/1v9VN9JN7fWIv1fIlBNXRhibMnRavn0M2Bx6AohtZ_jc/edit#heading=h.j8p0w0bugajb

SH: Link to document.
... possible actions need to be visible.

AC: Michael Gower's comments.
... "I feel like the order of the bullets is almost backwards. I'd like to lead with the most common exceptions and progress through to essential. "
... "Skip bullet comments

In regard to "The control is provided specifically to enhance the experience for keyboard navigation" is there any other thing than skip links? If not, I think we should specifically call them out."

<Rachael> https://www.npr.org/

<Zakim> Rachael, you wanted to answer other than skip link example

RM: NPR has an example.

Dm: trivial to make a button/control . Could be a technique.

<Jennie> * Laura - I'm ready to scribe once you finish David's point

Dm: like nike
... would like to move forward.

<Jennie> scribe: Jennie

Alastair: The keyboard navigation one is ok
... David's comments in the survey are to move forward
... Sukriti is also suggesting to remove the multistep process in bullet 3 which we have discussed
... Wilco (reads his comments)
... he is suggesting locate interface components or find

Sukriti: I want to clarify the comment
... To have some kind of an entry point to controls on the same page
... Going into the detail page then having access to it
... for example, emails
... I'm good with leaving it there. It does have alternatives, just not the best one

Alastair: Wilco says (reads his comments)
... I'm not sure what you mean by general exception
... He is not on the call
... It might be he is looking for it to be on the same page

David M: I think identify was the word we really wanted

scribe: The identifier - identify indicates here, right beside it
... Information to locate is not as strong
... We almost want to say label, but it is really identify
... If there was a fall back - if you cannot find it

<GN015> +1 to David

scribe: that could be in labels or information

Alastair: Our intent is to identify that it is a control
... Overtop of each names below, hover over it to find out more...but I would not put that up front
... I think we can make that clear with the understanding document

<Zakim> Chuck, you wanted to say "A mode of operation exists whereby information needed to identify user interface components is visible without requiring pointer hover or keyboard focus,

Chuck: I'm not targeting any specific word
... But the use cases, and needs
... You want full screen components, others need full screens
... Leads me to "mode of operation" from other SC

*hoping Chuck will paste that in

*thank you!

Alastair: I think we will drop the last bullet - that will be building it in
... My 1st question
... Would we be promoting that type of setting as a way to meet this criteria, or would people avoid using hover in the way we are trying to prevent?

<Zakim> JF, you wanted to suggest adding "active" controls

Alastair: It would change the emphasis from don't do this (apart from these scenarios)

John F: I like where Chuck is going

scribe: I would propose 1 change - add active controls
... Do we need to have all controls visible
... I'm thinking like in tab panels
... There are controls but they are in a hidden card
... Specifying to active or relevant - this will cover what is deliberately hidden for a good reason

Alastair: I think that applies whether it is Chuck's version or not

John F: I think we want to be sure we address the scenario when things are deliberately invisible

Alastair: Would they trigger something on hover?
... I think we have covered that

John F: We have disabled buttons on a form

scribe: And stacked tabs - links and other controls on hidden tabs should not be made visible
... It is part of the design

<david-macdonald> I can speak to that

scribe: We don't want them to have active tab focus
... It could be in the Understanding Document, or word smith to make it clear
... The text that Chuck proposed leaves some ambiguity to those use cases

<david-macdonald> visible entry point covers that in the note

Alastair: I see those use cases as well, but haven't come across one that would be revealed on hover

David M: John's question about if they want to hide them - we have a note at the bottom

scribe: Controls are visible through a visible entry point
... 3 tabs, 1 inactive...the visible tab is a visible entry point
... Regarding mechanism - Chuck's suggestion
... I really support Alastair's response
... We want to tell people not to do this
... It is harder for a person with a cognitive disability to determine this. The last bullet allows this but doesn't encourage this

<Ryladog> +1 to Davids point

Gundula: I want to respond to tabs being hidden
... The hiding is not in the technical sense - you have lines indicating they are there
... They need to be visible to see there are further tabs
... To see there are things to navigate to

<JF> @Gundula, not "tabs' but controls on hidden tabs

Alastair: I don't think anyone is suggesting we need different text for that scenario
... Moving to Gundula's comments
... (reads comments)
... I think this comes back to a point someone else made

Gundula: I think for normal user, or whoever reads it - user interaction is more understandable
... Input is understood as text that is copied or pasted in

Alastair: User interaction could be a click, and that is covering more than what we would want to
... If we want controls available without click that undermines menus and other things that are not a problem

Gundula: yes, but there may be a wave gesture too

Alastair: Yes but we would be creating false positives in the meantime

Gundula: Could you explore this more?
... If not in an adventure game - what is the negative use case?

Alastair: If we have controls only appearing on hover
... It seems like it might expand the scope in ways I cannot currently predict

David M: I agree with your instinct

scribe: The COGA task force - we trust what they come up wtih
... We want to make it as tight to the original intent as possible - with the identified problem
... unless you have done a thorough study of it

Gundula: If a user remembers that he needs to hover, such as to access the pause button, how will they remember they need to click? I don't understand.
... Why is click ok and not hover?

Alastair: It wasn't raised as an issue originally
... It comes to can you identify what is interactive

David M: We had a success criteria called affordances at one point, but couldn't figure out a way to get it through, and it would address all of this

scribe: It would make things visible, and obvious what they are

<stevelee> yes - should be clear from inspection without any interaction that an element is interactive

<alastairc> Steve - any thoughts on including click?

scribe: If you don't know what it is, clicking or hovering, that's true...But this has been moved to WCAG 3
... That's why we are going forward on that

Alastair: One aspect: things like menus are obviously hiding controls
... The thing you are clicking on is obvious
... The things which were hidden that have appeared on click
... I would have interpreted this to mean things that are already hidden
... Whereas if you hover ...

<stevelee> no more than you are saying

Gundula: I don't consider a menu hidden - a user clicks a button, for example
... It is not hidden in the technical sense
... The note specifically states that it does not talk about menus

<stevelee> you mean only pull down / pop up menues tha tare not visible?

Sarah H: One way to look at it is we are trying to address things that are not recognizable as interactive

scribe: If you are clicking on it, something about it said "click on me"

<stevelee> +1

scribe: We need to keep the focus really tight - on things that don't say "click on me" or "focus on me" - to address that shortcoming

David M: It is all about visibility and if you are having something clickable - there is not something that shows up on click, it shows up on hover

<Zakim> Rachael, you wanted to state that if we use click, we expand possible affects to navigation elements in single page apps.

<Jennie_> scribe: Jennie

<Jennie_> *had to refresh

<alastairc> scribe: Jennie_>

<alastairc> scribe: Jennie_

*thank you

Alastair: Where we are at the moment
... We are trying to keep the size to no more than what we have at the moment
... We would be going beyond our original intent of scope

It is not an appropriate time to be adding to it

Alastair: It is potentially true on the assumption that if you can get to the functionality then it is not an issue
... Re wanting to drop the user agent exception
... I think it was for title attributes
... We have several techniques already that are improved by adding title attributes
... We don't want to encourage authors to create their own
... That is not the intent of this success criteria

Mike G: In regards to user agents - the idea here would be that not every browser implements a radio button in the same way

scribe: We don't want authors second guessing
... Standard UA components
... Especially when we bear in mind - most things are not established form fields
... It covers us on common HTML elements
... I didn't see this as a show stopped - needing to have it in

Alastair: I don't remember there being a specific issue on this, but Gundula raised it in the survey
... I think it was for title attributes

David M: We weren't specifically thinking about title attributes, but...

scribe: It was mostly because HTML - we don't want people to have to override HTML to make it happen
... In the 2.1, 2.2 series - there are more grey areas
... It is good form not to get caught in a formal objection on things the browser does by default

Alastair: Gundula - would that be an objection?

Gundula: I do not agree
... Authors might decide to create their own controls, to improve the user experience, and they might be punished by this
... And why should the user agent get away with these deviations?

Alastair: My experience with developers creating their own controls is that it is often worse - experiences may vary there
... I'm trying to think what else, beyond title attributes, that is built into the browser and works on hover
... Can anyone else?

Gundula: what is the issue with the title attribute?

Alastair: It is the only thing I can think would be exposed on hover

Gundula: it is not interactive

David M: If there is information in the title attribute

scribe: If that gives extra information
... Because you cannot get to it with keyboard
... We could pull it out if we wanted to - it is covered by 2.1

Mike G: I am wondering if we called it out in the draft - asking if people have examples of where the exception to user agent is necessary or not - we could get public feedback

scribe: I would hate to strip it out if we don't have examples

Alastair: Given the whole version is new, essentially
... This will be one of focus when we go out for review
... The user agent aspect is new
... I would flip it around - take it out, put a note in, ask if there are user agent functionality that should get exceptions

<david-macdonald> I could live with that

Mike G: I can live with it either way

<alastairc> ACTION: Put note in requesting public comment, remove the bullet.

<trackbot> Error finding 'Put'. You can review and register nicknames at <https://www.w3.org/WAI/GL/track/users>.

Alastair: last comment was mine
... I feel it still catches false positives (reads from his comment)
... Defer to WCAG 3.0 is what I put as an option (chair hat off) that is not something I will massively object to but it is a concern
... I can live with that
... We have some in between examples

<alastairc> Poll: +1 for inclusion in WCAG 2.2 draft, -1 for defer to WCAG 3.0

<david-macdonald> +1

<Ryladog> +1

<sarahhorton> +1

<alastairc> +1 from Mike Gower

<GN015> +1

<morr4> +1

Mike G: I would think adding full screen

<Raf> +1

<MelanieP> 0

<alastairc> 0

<Ben> 0

Alastair: Yes, we can do that

<Sukriti> +1

<Jemma> 0

<Rachael> +1

<JF> 0

<AWK> +0 am concerned that there are too many edge/confusing cases on this

<laura> +1

<JF> (+1 to AWK)

<Jemma> (+1 to AWK)

Alastair: I think it would be useful to have a couple of people, fairly soon, update the Understanding Document
... And add some of these examples to make it clearer
... Please put in a comment if you are willing to help

<david-macdonald> sure

<Rachael> Reminder that when the understanding is updated, we need to address JF's concerns from last meeting.

<sarahhorton> sure

Alastair: John F's conversation from last meeting - look at Jonathan Avila's comment about adding in low vision

Focus visible updates https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates2/results

Alastair: We have the most issues on this

Updating the size metric

Alastair: The update in itself caused some confusion - one is an adaptable area, the other prescriptive
... I tried to come up with a 2nd part of that size area

<alastairc> New metirc: at least as large as a 4 CSS pixels border along the shortest side, and no thinner than 2 CSS pixels.

Alastair: The 1st part is unchanged, and a new bullet for this metric, which is in addition

<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-5.html

Alastair: It was based on going through the odd exceptions that people brought up
... I put together a test page with a table of how different some of the more extreme examples were
... If it is small, like a 1 character link
... It is a grey scale page
... The basic principle: if you look at 100 pixels square and work out the area - that is 4 pixels on the shorter side
... This applies the logic
... 2 people agree
... Mike can live with it
... Gundula had comments
... (reads comments)
... Based on some of the research and experience with the low vision task force
... the 1 px dotted line shouldn't - it can be easily missed
... and it often doesn't have maximum contrast
... Anything with 2 px wide
... that is why the minimum was set - the dotted outline was not a good minimum
... For the new metric: it requires a thickness and an area
... If it is thick (2 px or more) it does come into the visible range

Gundula: I understand it is visible, but is it identified as a focus indicator?
... If you have a spot on the page and you try to find the focus
... like embellishments like the half moon - are they identified as focus indicators?

Alastair: I think so
... The other aspect is there are obvious indicators or indicators that look pretty obvious and it feels like they should pass but they are being caught without this update
... Yes it could allow some less than ideal indicators through, but it could allow for some good ones that shouldn't be caught

Gundula: You said that low vision users have been asked, and (missed the end of this)

Alastair: If you search the github it should bring up those issues

<Ryladog> anti-aliasing setting change should not be required

Alastair: From the anti-aliasing - it becomes less of an issue except in the 1 px range and sometimes it is really bad
... Is this ringing alarm bells for anyone?

David M: I am just looking at example number 6

scribe: Contrast change pass

<alastairc> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-5.html

scribe: I did a comparison between the blue and green outlines and got 2.3 to 1

Alastair: It is black and white!

<david-macdonald> https://alastairc.uk/tests/wcag22-examples/focus-more-visible-3.html

David M: we are in different places

Alastair: The one that ends with - 5 is the one you should be reviewing
... If you find where that link was, please let me know
... There is a lot of detail in there

<david-macdonald> It was a link in the github

Alastair: The problem we were trying to solve that Jake raised - if you add another width to the button it fails

<Jemma> as a side note, left border color tends to indicate "selected", rather than "focus"

Alastair: The new metric ties the metric to the fixed side of the button and allows the text to increase, and not to fail
... For Jemma and others, we are not encouraging the examples I put in here. The Understanding Document will keep to the full perimeter and the examples

Mike G: I encourage people to remember these are the edge cases

scribe: I think it works well from that perspective

<Jemma> another note- In ARIA APG, we do lots of high color constrast testing, 1px seems not to be enough.

scribe: It is addressing real world experiences

Alastair: I feel like not enough people have looked at this one yet
... We will hold it over to next week
... To make sure more people get to look through it

Min area for unfocused/focused controls

Alastair: Abi asked if something increases in size - you have changed the size metric

<alastairc> https://github.com/w3c/wcag/pull/1577/files

Alastair: I think in common sense you would realize it should be in comparison to the unfocused control
... This update changes it from the perimeter of the focused control to the unfocused control
... Gundula said (reads her comment)
... I see what you mean - focusing on something with a light indicator can make the control look smaller

Gundula: I mean the control can be inside
... A blue button with a white indicator, the indicator wouldn't touch the white page background - it is inside the control.
... How should it be measured?

Alastair: I don't think that impacts how it should be measured
... We have things like change of contrast - wouldn't be logical to keep the size metric?

Gundula: It might make indicators fail which are easily identifiable

Alastair: I don't think that changes

<Jemma> For Gundula's case, I think ARIA APG example adds extra pixels around the button.

Alastair: We do have an example in the techniques
... There is also one in the Understanding Document
... We will come back to Focus Appearance next week

- DRAFT -

AG teleconf

12 Jan 2021

Attendees

Contents

Focus visible updates https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates2/results

Hidden controls update (question 1 only) https://www.w3.org/2002/09/wbs/35422/hidden-controls-12-2020/

Focus visible updates https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates2/results

Updating the size metric

Min area for unfocused/focused controls

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output