AG working group -- 11 Feb 2020

<laura> Scribe: Laura

<AWK> +AWK

Silver name https://www.w3.org/2002/09/wbs/35422/silver-naming/

AC: Popular survey
... proposed name "W3C Accessibility Guidelines"
... 14 I can live with "W3C Accessibility Guidelines"
... 3 - I can live with "W3C Accessibility Guidelines" but think the following name (see comment) would be better
... 1 - I cannot live with "W3C Accessibility Guidelines" because (see comment)
... it preserves the "branding" of WCAG, and it doesn't restrict us to web content.
... one suggestion was community. but concern was not as authoritative.
... David Fazio wanted it to be content. but it is needed to be more than content.
... name will go on FPWD and there will be a CFC.

awk: John Rochford said that the It appears to me there is a significant mistake in the guidance above. It says, "backwards-incompatible". I think it should be "backwards-compatible".
... that is not what we are saying.

<AWK> AWK: To be clear, we are saying that WCAG 3.0 is likely to be backward-incompatible with WCAG 2.x

AC: JF had a comment about successors. That is a bit premature.

WCAG 2.2 hidden controls https://www.w3.org/2002/09/wbs/35422/silver-naming/results

AC: some old comments. 4 more recent ones are up to date.

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

<alastairc> Doc: https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit#heading=h.zumckw268dp

RM: we met and discussed.
... email is a good example.
... added a concept about persistence.
... personalization is on track. but is at risk.
... reworked understanding doc based on comments.

AC: wilco said “If a process has two buttons to progress to the next step, neither of them is needed. I suggest "used" instead of "needed”.”
... not sure about that one.
... both are required. understanding doc thing.

DM: working with retailers recently.
... is "persistent" meant to meant through the entire process??
... more examples have hidden things.
... making all-in-one forms.

<AWK> example of what David is talking about: https://css-tricks.com/exposing-form-fields-radio-button-css/

AC: that should probably be okay.

DM: will be controls as they become available.

AC: may need to make it more explicit.

dm: as soon as you finish a section them the next becomes visible. What does persistent mean in this contest. May need a definition.

<Zakim> AWK, you wanted to say that the note covers important ground that needs to be in the normative text

<kirkwood> does persistent mean available without scrolling?

awk: persistent means that it is always there. Problem for single page apps.

<alastairc> kirkwood - no

<kirkwood> ok

awk: think we want them to pass. need to scope persistency.
... needs to be visible when it needs to be used.

<CharlesHall_> but persistent in view is different than persisting in visibility

ac: wonder if its for active controls.
... maybe scope to without hover or focus.

dm: if it show/hide need to focus on it.

katie: before activation?

ac: need something around that.

awk: maybe triggered by interaction.

rm: goal is not to hunt around
... interaction was confusing.

ac: scope to active controls?

<CharlesHall_> active is also a state. which is different than can be acted upon or is not disabled.

ac: we don’t want to hide submit buttons.
... maybe adjust first bullet: visible without interaction
... wilco also worried about "programmatically determined”
... maybe remove that.

awk: why?

AC” Wilco said - This technology does not yet exist. I do not think it is a good idea to speculate about technologies that are not proven to work, and may never even come about.

<Zakim> AWK, you wanted to say concerned about "The equivalent control is persistent elsewhere within the page or process" not being needed

awk: don’t need to say: “The equivalent control is persistent elsewhere within the page or process"
... could having note.
... as long a can achieve the functionality should pass.
... okay to have controls that are not visible if not needed.

rm: within the page I understand your point.

ac: could take out page but leave in the process part.
... could take out “page or”

awk: concern if we get in habit restating in one part and not another, people may think it doesn’t apply.

ac: we can delete the first exception and explain in the understanding doc.

<Zakim> mbgower, you wanted to say how does this apply to a carousel?

mg: carousel example
... could fail it.

ac: carousel would need to be part of a process.

<JF> +1 to mike

mg: could be implied that it is a process.

<Zakim> Rachael_, you wanted to say it would likely fall in the media content exception

rm: depending on process it could be an exception.

<CharlesHall_> passively paginating through inert content is a process?

mg: carousel could be a media controller

ac: can explain in understanding.
... updating the doc. first bullet: The controls are visible without requiring pointer hover or keyboard focus

Detlev: wondering about equivalent controls a few clicks away.

awk: if it requires it then it must be visible.
... if it allows the user to continue should pass.
... needs to be carefully designed.

rm: should pass. even if the process is longer.

<kirkwood> +1 to Laura

ac: if hiding controls would be horrible for everyone.

awk: wondering about too broad of an exception.
... is it play and pause controls? or more?

ac: I was more than an image. more than video content

awk: do we define the word media?

ac: video may be the best term.

<AWK> https://www.irccloud.com/pastebin/fkOdZV7C/

rm: decorative vs content. decorative doesn’t need to be there.

JF: need to follow 2.2.2: Pause, Stop, Hide
... needs to be discoverable.

<mbgower> Why do we need the media exception?

<mbgower> How would a video be a step in a process?

ac: Pause, Stop, Hide requires a mechanism.

mg: video not a step in a process

Jake: could be that you have to watch a video as part of a process.

ac: seem like we can get rid of that.

<Brooks> What about audio CAPTCHA?

mg: made a few minor edits

brooks: how do you get by an audio CAPTCHA?

ac: we should have visible persistent controls.
... made quite a few edits.

<Zakim> mbgower, you wanted to say what does "active" signify in the first line?

mg: do we need the word active in first line?
... should be explained in understanding that could have next button.
... once a button is enabled must be visible.

ac: active for things that dynamically show and hide. but cover by controls needed to progress.

<alastairc> "The controls are visible at the time they are needed without requiring pointer hover or keyboard focus

ac: first bulled would be “The controls are visible at the time they are needed without requiring pointer hover or keyboard focus”
... wondering if we need both bullets.

<Zakim> Rachael_, you wanted to ask if the notes are still needed?

rm: do we need the notes anymore?
... can we delete them?

ac: yes.

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

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

<Chuck> https://docs.google.com/document/d/1DPtCqWHjrhj3QZ4afsqzmWDd-zMSf39RsMqSpR2QGCg/edit#heading=h.zumckw268dp

Controls needed to progress or complete a process are visible at the time they are needed without requiring pointer hover or keyboard focus, or a mechanism is available to make them visible.

<alastairc> "Controls needed to progress or complete a process are visible at the time they are needed without requiring pointer hover or keyboard focus, or a mechanism is available to make them visible"

<CharlesHall_> could we say pointer events instead?

ac: reads the proposed SC text.
... pointer events would be wider.

<CharlesHall_> includes long touch and force touch

scribe change?

<kirkwood> could we say “or a persistent mechanism is available to make them visable”

<Chuck> no can do, still fighting timezones.

<alastairc> scribe: david-macdonald2

Wordsmithing continues on the success criterion

<Zakim> JF, you wanted to ask if we define "visible", and does that definition include color contrast? (Does it nee that?) and to

<CharlesHall_> and visible does not mean persists in view

JF: do we want to define visible here. At minimum referencing colour contrast? I know that it sort of covered by other success criterion in a roundabout way but I wonder if we need to make it a little bit more direct
... can we define visible as far as 2.X
... visibility also needs to be perceivable

<laura> s/discussed /discussed /

JF: we have indirectly made that decision but we have not specifically called it out yet.

<Chuck> This is what it would look like: Controls needed to progress or complete a process are perceivable at the time they are needed without requiring pointer hover or keyboard focus, or a mechanism is available to make them persistently perceivable.

<laura> s/persistence /persistence /

<CharlesHall_> ‘persistently visible’ could imply that it persists in view (without having to scroll)

AWK: we can point it out and note
... go around and around with this. We can't identify all the additional SC's have to be remarked upon here. However we could say that visibility means nontext contrast and contrast

<mbgower> It is clearly covered by 1.4.11

JF: we've always had these requirements for size and contrast the specific location but never getting an explicit use case. So this sc is Building upon other success criteria

<mbgower> +1 to understanding doc. It's clearly covered by conformance

Alastair: could you live with it being in an understanding document instead because all these references can spiral

JF: Yes

AWK: notes are not normative

JF: right but it is in the normative document
... as we roll this out we look at these types of questions from people who were not involved in these Nuance discussions

Alastair: let's keep this back is clean as possible and move that type of explanation to the understanding document. Otherwise this type of thing could apply to a lot of success criteria

JF: I'll go with the flow just want to raise it as a point of concern

<mbgower> +1

<Rachael_> +1

<JakeAbma> +1

Alistair: with simplified and hopefully improved success criterion. Are you happy where it's gone?

<AWK> +1

<laura> +1

<Ryladog> +1

<kirkwood> +1

<JF> +.8 ;-)

<Brooks> +1

<CharlesHall_> + 1 if persistence and visibility are notes in understanding

+1 but wondering about the necessity of hovering to click or activate something

Alastair: we needed new technique, and an understanding document for this

<alastairc> David: confused by the focus, if I need to hover/focus on it, surely that is everything?

<CharlesHall_> i don’t have to focus or hover with a touch device – only tap.

RESOLUTION: Leave open, but almost ready

WCAG 2.2 Touch target spacing https://www.w3.org/2002/09/wbs/35422/target-spacing/results

<alastairc> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit

Alistair: we have more comments that target spacing. Comments are about target spacing

<JF> +1 to just using "targets"

https://docs.google.com/document/d/1ejG_7yaCI2xbEPqFZCbJgqGuu_kplEMtsO-XYJVbTkg/edit?usp=sharing

David: I've rewritten the success criterion try to make it easier to understand, while trying to preserve the meaning

<alastairc> Pointer target spacing: For each target that has a width or height of less than 44 CSS pixels, any dimension that is less than 44 CSS pixels has a minimum overall size (target size plus spacing between targets) of 52 CSS pixels except when:... (then same)

<alastairc> ^ alternative version

Alastair: I will drop and IRC things I've tried to do to address Wilco's comments
... I think I agree with Wilco's comments
... if I had a button and a horizontal group of buttons and its 30 pixels less than 44. If you've got 12 pixels a spacing on the right to the next button. At button and potentially want to the right fail. But on the left there is eight pixels is that fine/

<CharlesHall_> apologies / regrets, i have to drop off call

Jake: David your suggestion doesn't take into account a couple of circumstances by leaving out the 44. The less than 44 was partially what this was based upon and not the total distance of 52

Alistair: why make a greater requirement if they are less than 44. For instance if it is 40, that it would have to be 52 with the spacing.

Jake: I think that during the re-factoring of the sentences, I think we wanted for anything that was less than 44 to have that eight pixels which is recommended by big companies. So it's a combination of two separate requirements.

There always a weird gap between making it bigger than 44 if the base size of the buttons lesson 44. That's when you have to at the eight, and you end up more than what you started with. I create with the weird And what to do about it between 36 and 44

When you take the Amazon menu on the left I think it's 42 and that it would have to be 52, but if they added just to pixels it would be fine.

Or it could be perceived as a message to make everything 44

Detlev: I agree it's a weird gap in our hard sell and not easy to bring together. The reasonable's fallback position could be to say, if the target get smaller's the cumulative has to be 44 rather than 52. I think even 44 will be a hard sell

52 is quite a wide gap

Alistair: in toolbars would be very difficult. Will get a lot of pushback. If we get through with 44 as the size of the target or the target with the outer bounds, it would be quite good to get through I think.

Detlev: this is just my personal opinion. Sorry if I'm undercutting any of the mobile task force positions

Chuck: if we are critical with 44 that I don't need this question answered. Currently I'm confused as is why this strange gap exists. I don't need that explanations if we just say 44 that I don't care.

<bruce_bailey> +1 to stick with 44 rather than 52

Alistair: I know there's a reason, we went through several iterations. Jake explained.

Jake: there are separate recommendations from Microsoft and Google that there is space between targets.

Chuck: Microsoft and Google required eight pixels between targets. They also recommend 44 pixels.

<Zakim> mbgower, you wanted to say is 'adjacent' defined anywhere?

Alistair: but Google and Microsoft will follow this advice so it's just a best practice. I'm finding it hard to find an argument not to go with just 44.

MichaelG: is adjacent to find anywhere

<alastairc> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit

<alastairc> q/

Detlev: the intention is to make sure that the size is big enough that you can touch with the finger.

<Chuck> +1 to detlev

Delev: lined up vertically or horizontally

<Zakim> bruce_bailey, you wanted to ask about gap between 44 and 40

Detlev: agrees with the idea of 44 pixels, makes it easy to understand

<bruce_bailey> unmute me?

Bruce: I see a lot of failures of 44 pixels where it's just barely failing at 42 pixels are 40 pixels. So I want to keep it at 44 not 52.

Alastair: that seems to be the theme and if Detlev and Jake are okay let's go with it

Chuck: as long as we don't override companies best practices.

<Chuck> +1 to 44 fixed

Alistair: 44 pixels is the smallest for big companies so I think were okay
... will reformulate this so that it's 44 in each direction height and width.

Chuck: what about a map or something like that

Alastair: that would be an essential exception I would say

<mbgower> 'between a control's edge and the closest side of any adjacent target...'

<Detlev> +1 to Mike's edit

Alistair: I think will cost comments will be primarily addressed with our new direction.

<mbgower> ...between a control's edge and any adjacent target... (and I don't see why you need 'axis of agency')

<Detlev> I meant suggestion, not edit...

WCAG 2.2 SCs catchup

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

<mbgower> thanks!

<laura> bye

preset+

- DRAFT -

AG working group

11 Feb 2020

Attendees

Contents

Silver name https://www.w3.org/2002/09/wbs/35422/silver-naming/

WCAG 2.2 hidden controls https://www.w3.org/2002/09/wbs/35422/silver-naming/results

WCAG 2.2 Touch target spacing https://www.w3.org/2002/09/wbs/35422/target-spacing/results

WCAG 2.2 SCs catchup

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output