W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

05 Jun 2018

Attendees

Present
AWK, AlastairC, Detlev, Rachael, marcjohlic, JakeAbma, Makoto, Brooks, jon_avila, Greg_Lowney, Kathy, Glenda, Mike_Elledge, KimD, david-macdonald, JF, kirkwood, gowerm
Regrets
Chair
AlastairC
Scribe
Rachael, alastairc, Mike_Elledge, Glenda

Contents


<alastairc> AWK - started meeting

<Rachael_> All: General excitement and congrats on WCAG 2.1 release

Call days & times

<Rachael_> scribe: Rachael

<Rachael_> Alastair: Considering keeping the Tuesday call and removing the Thursday call for the time being.

<Rachael_> Thursday was added during the WCAG 2.1 runup. Hopefully the push will drop off for the next few months.

<Glenda> +1 to removing the Thursday call for AGWG

<Rachael_> Andrew: We've had a ton of calls, some weeks more than 5. I think the Thursday call can interfere with the taskforce calls and we should go back to the single call on Tuesdays. We should also discuss the time of day of the Tuesday call.

<Rachael_> We want to be able to do more work and some of the asynchronous work can better support the time we use on the calls. I would love to get back to 1 call a week.

<Rachael_> +1 to removing the Thursday call

<KimD> +1 to one call/week

<AWK> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20180601&p1=283&p2=43&p3=136&p4=438&p5=248

<Rachael_> Alaistair: I also wanted to discuss the possibility of rotating times to accomodate time zones. Current time supports US and Western Europe but we have people on the call who it is at midnight. The link Andrew shows that no possible time is good for everyone.

<Rachael_> If we did move it to another time, would we loose a lot of people? Also, if we added a 9am UTC time (5 Tokyo, 1:30 Banglador), would that encourage more participation from folks in India and Asia?

<AWK> I suspect Makoto might approve a non-middle-of-the-night call

<Glenda> What if we rotated the call every other week (to a different time)?

<Glenda> Rather than a 2nd call

<Rachael_> Michael: I support the idea but I worry at where you start? Would enough people participate? We may want to try it monthly and then build participation. (Just a suggestion)

<Rachael_> Makoto: It is 12:15am my time. It used to be 4/5 am a few years ago. It was harder to wake up early in the morning. I am fine with this timing.

<Rachael_> Alaistair: Do you have contacts with others who would be encouraged by a more reasonable hour? Or would a catch up call once a month help?

<Rachael_> Glenda: I suggest a poll to people to ask them to suggest their top 3 favorite times. Include a statement that with a worldwide group, we know there is no perfect time.

<AWK> AWK: not sure if better to have an additional alternative time call (hopefully with some overlap in attendance) or every other week time variation

<AWK> AC: Now seems like a good time to experiment

<AWK> ... We will do a survey.

<KimD> +1 to poll

Techniques & Understanding docs process

RESOLUTION: No more Thursday calls are planned.

<alastairc> scribe:alastairc

AWK: Wanted to discuss the approach with the group. Need a good cadence, so the group can rely on it.
... part of the challenge, is that there is an unstopable flow of issues, emails, etc. Hard to keep up.
... people don't /can't always engage, until there's a CFC. Then you know you can ID problems, which is great, but not sure that's the right behaviour.
... one advantage for techniques & understanding is that we can change them when we want, not a TR doc.
... what process should be have? If you have a change, put in some work that creates a pull request, people support it then great. Should end up with a day (e.g. wednesday), where we accept PRs unless people raise concerns.
... If someone then says (after being away) whoa, that creates a big problem, we can reverse it the next week. Doubt that will happen a lot.

<scribe> scribe: Mike_Elledge

mg: Good to have a new stamp on new technique and preface describing new tech and link. Then new stamp can come off at a particular amout of time.

awk: A label that describes new technique in Github?

mg: Actually in document, not Github. New in parenthesis, maybe date stamp at top too. More affordance about maturuity of new technique.

<Glenda> +1 to for a date stamp (and would love the ability to pull things up by date)…so we could review the latest quickly

awk: Wonder if date stamp would be sufficient. Not sure if can filter, but could sort by date would address the issue.

mg: yes, that's right. Maybe date stamp on last revised. Especially for SCs that have new technique, ppl should be able to have some context.

awk: Like the idea.

mg: Since we're going to be tweaking techniques, can look to see what's been added.

alastair: Almost an externally facing thing, as well as within group not knowing what ppl should be checking.

<AWK> https://github.com/w3c/wcag/issues/320

alastair: We'll ask Michael about date stamps.
... Hoping ppl will be writing techniques, would like it to be easier process. List things in github that are marked for ready for review. No objections go live.

<AWK> Proposal: changes to techniques and understanding that are ready to go by Friday morning will be approved on the following Wednesday. Any items that need further discussion will be on the agenda on Tuesday.

dm: Would be good incentive for ppl to remain engaged. All of us have day jobs. Keep an eye on cfc, but in future important to have mechanism for keeping on track (snooze, you lose).

<Glenda> +1 to “you snooze, you lose (but you can get changes made in retrospect)

<alastairc> +!

<alastairc> +1 even

awk: If new techniques ready Thursday, look at it, looks pretty good, then plan to approve on following Wednesday. During those few days send out email that "ready for review". Would help drive discussion on Wednesday if we can't agree.
... Not so much snooze you lose, but if go into deeper sleep may want to add changes. Still could.

mg: Wondering if more of a hive model would work better for consistency. If consistency in style is important, then several ppl could review for editing.

alastair: Review by editorial team would be helpful.

mg: Happy to have that role. So long as it's in my email by certain date.

awk: One concern that it might not work, when ppl have lots of thoughts about techniques, will still want engagement. How best to do that.

mg: Some basic QA process before it appears for comments.

<Glenda> what about an EO reviewer?

alastair: Before tagging for review someone has looked at it.

mg: If not in good form, would be pushed back by editor.

awk: Additonal EO work on understanding docs, sometimes submitters, have to make sure that there's sufficient time.

alastair: so it work with their cadence.
... more comments on techniques process.

awk: Core question, process for non-normative docs wanted, without being as formal as for SCs.

mg: Any reason couldn't be a survey?

<Glenda> +1 to making non-normative docs easier to publish and change. (easier than normative docs)

awk: No, could work.
... Can we do this in less than a full SC, how to do that while retaining oppty for people to respond. On a regular interval, too. Soemone may want to work on them on a more scheduled basis.

mc: Need to have method for merging.

mg: Too much to respond to pull requests?

alastair: an interesting feature, but wonder if we could manage that with labels in github.

mc: What if there are comments? how do we determine when ready to go ahead.

mg: Put comments in text where you thought there were issues. Have threads from there.

alastair: Think need either survey or github. Then a call to decide if blocking or not, andrew or I decide if ready to go.

mc: How are we making this simpler than cfc process. Not clear that this is.

alastair: Have pull requests for github techniques, put forward, initial review by editors, then survey which points to pull requests. Then no coimments or objectiosn after Tuesday call, they would be ready to go.

awk: Using a Can you live with this threshold, not sure whether we've cracked that or not. When we have a CFC, it has to be just so, then when it goes through have 48 hours. Have to be very editorial. As opposed to this, could make changes.

mc: Makes it all fuzzier for me whether should merge it.

awk: We will have to document this process for group to respond whether they're (and we) are comfortoable with thiss.

zakim: next item

<alastairc> https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#List_of_Techniques

alastair: have the techniques list

Issue resolution: 913 & 914 (Non-text contrast understanding doc)

alastair: dive into the techniques.

Thanks, JF.

<alastairc> https://github.com/w3c/wcag21/issues/913

alastiar: non-text contrast, hover state or not

<alastairc> https://github.com/w3c/wcag21/issues/913#issuecomment-393975067

alastair: last week's discussion. Require visual identifiers rather than specific boundaries. Hover state has add'l info, so not as critical as text.
... Vermillion comment about certain info not always there for buttons. Comments?

mg: Thnk that we need to have a langugae stating where hover does not have redundant cue, must have 3:1. Need more work on it.

alastair: wehre sc says required, dont' have pointer for button must have something else. some visual identifier.

mg: either 3:1 or other identifier.

awk: Intent that 3:1 important fo rhover state, text or graphic can't suddenly go low contrast (espc. screen magnifier). Don't think that it's about hover being used to identify that it's a button.
... Many buttons don't have hover state.
... Maybe that's waht we have to clarify. 3:1 requirement fo rgraphicl content is important.

alastair: no requirement for hover state wrt visual indicator.

jf: Not sure if related to this or 914, but less concerning than hover is visible tab focus. Related to hover as focused state. Disconnect that we're not saying that tab state needs color idenficiaiton as well.
... Wheter hover or tab both need to maintain gthe color contrast.

alastair: Discussion was about change in state (?).

jf: See them as all interrelatedd.

alastair: Resolve 913 first?

<Glenda> Hover has a pointer that is visible

mg: State requirements for 3:1, focus, hover, check, expand, collapse, etc. if comfortable that hover is only one that doesn't have to meet 3:1, then should have reasons why it isn't ahs important, and when it should meet 3:1. Are we all comfortable that hvoer is not as imporatnt as focus or select.

alastair: there are other indicators for hover.

<jon_avila> States could also be indicated with icons like expanded/collapsed

<JF> yes, and those indicators need to have sufficient contrast

<jon_avila> yes

alastair: yep. so if tehre is an indicator that's what we're requiring. Indicator shave to have sufficient contrast.

<Brooks> +1 to indicators needing sufficient contrast

<Glenda> scribe: Glenda

<Mike_Elledge> sorry-- for some reason microphone didn't work.

Jon: if an icon shows hover state, icon has to meet contrast. If text, the text still needs to meet contrast on hover. If there are additional visual indicators (redundant) they don’t all have to meet contrast…only 1 visual indicator of the hover state must be visible. And if there is no hover visual state, that is okay too. Equal for all.

<alastairc> https://www.w3.org/WAI/

AWK: For example, on the WAI home page, there is a bright high contrast yellow line that meets 3 to 1. Which means the button’s lack of left/right of the button…because the yellow line is enough.

<JF> +1

<jon_avila> call in user 2 put us on hold

<jon_avila> relaxing

<jon_avila> *yay

<KimD> *whew!

Gower: hover should not have a get out of jail card, just because there is a visual redundancy of the pointer.

<jon_avila> Agree Mike -- I beam is on all text and input fields.

<Detlev> goverm - we are talking hover, not focus

Gower: We need to decide at what point do we consider something necessary to meet this. And we must still require clear focus indicators, selection states...

<jon_avila> If the author has no hover state changes at all -- is that ok?

Alastair: that is compatible with the proposed response of 913.

<Zakim> gowerm, you wanted to say i would be HIGHLY concerned if we said that a complete lack of an indicator for state is fine

Detlev: maybe we are losing the distinction between states and hover. There is no requirement for a visual hover.

<Detlev> That button has no alternate state - so that would pass IMO

<Greg> I would say it passes, because if it had no hover indicator at all it would pass.

JF: when I mouse over a button, I can tell I’m on hover, because the pointer changes from an arrow to a hand. That is a visual indicator. It is enough.

AWK: if you do a custom element that does not trigger the pointer change, you will need to have a visual indicator of hover state.

Brooks: concerned that we shouldn’t rely on user agent, because the user agent could break this.

Gower: that is part of this SC. The SC does not force developers to fix something that can be solved at the user agent level.

Detlev: I’d feel more comfortable to just exclude hover. To operate something by the mouse, you have to see the pointer. If developer hides the pointer, then it is unusable for everyone.

<gowerm> Excluding hover is the easy way out. We can put our rationale in the understanding doc. Then nothing we are using to rationalize hover gets us in hot water for other states

<gowerm> +1 to Detlev

Alastair: but we currently have “hover” in the normative definition

Jon: I don’t agree with removing it. People rely on changes to know they are in the clickable area. But I would accept the mouse pointer change is sufficient.

Alastair: Maybe we just need a sufficient technique with mouse pointer meeting hover.

Glenda: +1 to alastair’s suggestion

<Detlev> this is a UA issue though

Glenda: +1 detlev

<AWK> +1 to Jon

<JF> +1 to Jon

2.4.7 requires focus visible

<Detlev> I can certainly live with that

Gower: if someone has an expandable/collapsible section and there is NO visual indicator…then that is equally unusable by all. Not an a11y fail.

<jon_avila> If there is no visual indicator for anyone then it seems like a problem for everyone. Addressing this would require another affordance requirement

<jon_avila> I am not saying it has to contrast with new state and prior state

Alastair: think we are in the right direction. Proposed response is in the right direction. Will need more examples in understanding.

Detlev: need to emphasize what “active” state means on touch interfaces.

Alastiar: can you email the list of an example of that

Detlev: I will experiment and mail to the list.

<alastairc> https://github.com/w3c/wcag21/issues/914

AWK: I will add some clarification to the official response and the pull request 943

<gowerm> +1 I also think we should capture the cross-reference to 2.4.7 Focus Indicator

Alastair: next comment is on boundries and states. AWK gave a very comprehensive response. Solved by changed wording on new SC. Still hard. Can be helped with understanding.

Glenda: I suggest solving many of these questions with sufficient techniques

<Detlev> fine

Alastair: any objections to the proposed response.

AWK: I will update and label with “for implementation” followup

JF: what about when you modify the background color, but you don’t modify the tab state. This leaves a loop hole.

<Detlev> I don't get your point John

Alastair: hold on, that is the next issue, lets first resolve to accept 914, then we will move on to the exception.

<alastairc> https://github.com/w3c/wcag21/issues/914#issuecomment-393980024

<alastairc> https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0648.html

JF: visible focus state is natively established in each browser. It presumes the native background color is white. If you change the background color, you must change the visual focus indicator.

Jon: different browsers put the focus indicator in different places

Glenda: When I wrote this, I intended to make the developer responsible for the visual focus indicator IF they changed the visual focus indicator OR the background behind that visual focus indicator.

AWK: in some user agents don’t they adjust the contrast of the of focus indicator based on context?

Jon: IE does try to do this

AWK: if you make a conformance claim and you are using two User Agents, (IE and Edge) and they user agent adjust the color of the focus…based on the context…then the user agent took care of it for you. But if you use Chrome/Firefox…you’d be responsible. Is that what you mean?

JF: when I test I use webdeveloper toolbar, I turn off CSS and can see focus. If a content author modifies any aspect of the focus indicator (the color of the indicator and the backgroun), then they need to be responsible for the contrast of that focus indicator.

<jon_avila> I'd also remind folks that we only require one side right? either inside of focus ring or outside but not both. For Chrome if the blue outline fails on blue background but passes against black button border that might be ok

<Zakim> Brooks, you wanted to say a component's color contrast ratio is dependent on a comparative analysis with parts of the page that are outside of the component (background, adjacent

Brooks: want to voice my support for what JF is saying.

<JF> +1 to that Brooks

<Rachael_> +1 to John and Brooks

Brooks: this is supposed to be filling a significant gap in what was in WCAG 2.0, make sure focus indicator is visible.

<KimD> +1 to JF - I think his point is very well taken

Jon: all the browsers do this differently. I think we agreed that it only has to be one side.

Glenda: Jon, yes, just one side.

<JF> but with that Jon, the page author has changed the visual presentation of focus state, so yes, I would agree with the "1 border" issue

<Zakim> gowerm, you wanted to say that it's pretty unsual for folks to stick with the user agent presentation now

Jon: we only require one side of the focus indicator to contrast. either inside of focus ring or outside but not both. For Chrome if the blue outline fails on blue background but passes against black button border that might be ok

<JF> @Mike, I am seeing about 50/50 split myself, during numerous training sessions at multiple client sites

gower: most developers are going to be caught on this, because they are changing the focus indicators (and or the background). I don’t think we need to worry about this level of detail. This will be called out. If the dev touched the focus indicator (or the background) I would flag it, if you can’t see it.

glenda: +1 to what gower just said.

<jon_avila> The challenge is that every browser is different -- For example browsers on Android might use green with the keyboard.

Chuck: is Understanding is agnostic to the browser?

alastair: impact is the exception will almost never occur because the background or the component will likely have been changed by the developer.

<jon_avila> and that was my concern that -- that everyone will be overwriting focus indicators

<jon_avila> CSS initial value

JF: if you write a plain html doc, and you do not supply a stylesheet. There is still a default stylesheet provided by the browser. When content author modifies the background, they are also responsible for making the focus indicator visible.

<AWK> I can live with John's interpretation of controlling the focus appearance when changing the background color as a technique but not as a failure

<gowerm> +1 to get the user agents to improve their defaults

Glenda: plan to get user agents to provide a very obvious focus indicator (oreo indicator - black/white/black) so in the future we will all be able to see the focus indicator.

<JF> +1

Chuck: Glenda, you are going to the user agents and ask them to improve their default focus indication. So, our standard and understanding should be browser agnostic.

<Zakim> JF, you wanted to say that the focus indication does not need to be the "square" box-model appearance

JF: reminder that focus indicator does not need to be a square box.

<KimD> +1 JF - control that has sufficient focus renders the browser outline secondary or even moot

<gowerm> +1 914 response looks good

AWK: lets get to a conclusion on 914. propose we close that one off with proposed response.

Glenda; +1 914

<KimD> *sufficient contrast on focus

<jon_avila> When you flip backgrounds you can end up in a situation where you can't tell the non-focused state from the focused state

<alastairc> https://github.com/w3c/wcag21/issues/914#issuecomment-393980024

<gowerm> https://github.com/w3c/wcag21/issues/914

<Detlev> +1

<Makoto> +1

<alastairc> +1

<Chuck> +1 914

RESOLUTION: accept proposed response for 914

alastair: regarding state, focus indicator and background, I’ll have a think and send more info to the list.

Happy WCAG 2.1 day!

<alastairc> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. No more Thursday calls are planned.
  2. accept proposed response for 914
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/05 17:03:26 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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/It is 11:15pm my time/It is 12:15am my time/
Succeeded: s/you loose/you lose/
Succeeded: s/jail card, because/jail card, just because/
Succeeded: s/doesn't get/gets/
Default Present: AWK, AlastairC, Detlev, Rachael, marcjohlic, JakeAbma, Makoto, Brooks, jon_avila, Greg_Lowney, Kathy, Glenda, Mike_Elledge, KimD, david-macdonald, !, JF, kirkwood, gowerm

WARNING: Replacing previous Present list. (Old list: AWK, MichaelC, Chuck, ShawnHenry(for_persona_quotes), JF, gowerm, alex, kirkwood, Katie_Haritos-Shea, alastairc)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK, AlastairC

Present: AWK AlastairC Detlev Rachael marcjohlic JakeAbma Makoto Brooks jon_avila Greg_Lowney Kathy Glenda Mike_Elledge KimD david-macdonald JF kirkwood gowerm
Found Scribe: Rachael
Found Scribe: alastairc
Inferring ScribeNick: alastairc
Found Scribe: Mike_Elledge
Inferring ScribeNick: Mike_Elledge
Found Scribe: Glenda
Inferring ScribeNick: Glenda
Scribes: Rachael, alastairc, Mike_Elledge, Glenda
ScribeNicks: alastairc, Mike_Elledge, Glenda
Found Date: 05 Jun 2018
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]