W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

13 Aug 2019

Attendees

Present
AlastairC, AWK, Fazio, Raf, Jennie, JustineP, MichaelC, johnkirkwood, Laura, KimD, jon_avila, david-macdonald, Rachael
Regrets
Chair
AlastairC
Scribe
johnkirkwood, Jennie

Contents


<alastairc> WCAG 2.2 reviews Dragging only (1st question) https://www.w3.org/2002/09/wbs/35422/wcag22reviews/

<alastairc> Techniques & understanding updates questions 1-6 https://www.w3.org/2002/09/wbs/35422/AGWG_T_U_Aug2019/

<AWK> +AWK

<Jennie> I can scribe 2nd half

<johnkirkwood> I can scribe 1st half

<johnkirkwood> yes!!!

<johnkirkwood> ;)

<alastairc> scribe: johnkirkwood

WCAG 2.2 progress update https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JulSep/0128.html

Alastair: ... WCAG 2.2 update. Where we got to and what the plan is
... doing some reviews of potential SC we have had 19 ish
... 4 are progressing well. some updates some new
... another 4 with substantail questions
... 3 potential of being left out

<alastairc> https://docs.google.com/spreadsheets/d/11IKqjRFvkRd2dAfUiyc5whhB3yIYXvSiirWct7KQIB0/edit#gid=0

Alastair: orientation content change of particular interest, intially had jake
... does anyone know about it

I have it

Alaistar: memorization needs more support, david has done first draft can send around
... description of icons need someone to take it on

Alastair: moving on to timings
... new SC proposed to intial draft reviewed by TPAC so we can go through final list of good candidates. only have a couple more weeks
... after TPAC will work on understanding techniques early next year review. then after er3eview and candidated recommendations... it was in an email.
... any questions or comments?

WCAG 2.2 reviews Dragging only (1st question) https://www.w3.org/2002/09/wbs/35422/wcag22reviews/

<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results

Alastair: Detlev sent this through, link takes to you to querstionnair
... results second link
... laura no comment
... pointer gestures scope didn't include all drag, detlev tried to fill the gap on essential dragging need
... my main concern was feasability
... where draggin is only good way of doing rather tha essential.
... wondering if examples of dragging issue examples would be good to know
... any other questions on this WCAG 2.2 SC?
... or need more time?
... my only comment was an english thing lateral sideways up and down
... anyone can help on potential SC. There are a few that could do with a little more assistance
... the ones needed more focus were in question 2 in survey
... half an hour to look at it would be very useful
... I'm here!!!!
... if no comments have to consider draggin SC is a potential go in 2.2
... no questions or comments on 2.2 work?

Techniques & understanding updates questions 1-6 https://www.w3.org/2002/09/wbs/35422/AGWG_T_U_Aug2019/

Alastair: move on, because no questions

Updating Understanding 1.3.3 Sensory Characteristics #767

Alastair: on issue list first one is an update to WCAG 2.0 document

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

Alastair: a link to change.
... sensory 1.3.3 make change more explicit instructions

<Jennie> I can hear you

no

all good on my end

<alastairc> Question: Has anyone else lost audio.

<Fazio> I can hear

<jon_avila> I can hear you Alastair

Alastair: sorry andrew its mostly you with audiio issues
... couple of comments, M Gower not sure about what its to do with, particular example in understanding document. if alt text refers to shapes this would be a failure
... referencing color icons, not able to read out with all context

Andrew: to read through M Gower content? Not sure if he's asking if the SC means what it says. not quite sure

Alastair: i didn't think alt text fit into it

Andrew: no i don't think it does

Alastair: so answer probably is no to MG
... for this pull request Michael second comment doesn't figure in. the other is not a change in this pull request anyway

<laura> agree with keeping F26

could you write the resolution, sorry

Alastair: questions or comments?
... keep fe6 any objections?

F26

Michael: not sure about deleting file

Alastair: might need to create a new branch
... not seeing any objections

RESOLUTION: Accept PR 767 ammended to keep F26

Errata, Motion actuation #733

Alastair: same survey new topic
... potential arrata change to 2.1 on motion actuation

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

Alastair: pull request shows change
... reason behind in in issue 7.2.7 ? not right issue?
... is this supporting intent of mobile accessibility task force
... it is in question

Andrew: seems like a big change to a. normative SC worry about making a change of this significance without more digging into it
... don't want to be too casual about it

Alastair: because not a huge amount of respones happy to put on hold
... in support of change it looks more different than it is
... at the moment it appears from first sentence implies both operating with motion was struggling to write a technique

MichaelC: device motion and user motion I assum equivalent to accessibility supported interface

Alastair: and goes on to say can be disabled

Michael: first part is redundent

David: supported with interface technology

Alastair: user interface components and disabiling accidental triggering

Michael: need to understand it

DavidM: unless works with assitive technology have fall back buttons. it is kind of redundant

Alastair: applying supported interface to prevent activation having problem with
... put this on hold
... writing supporting documentation

can you do resolution?

RESOLUTION: On hold pending further comments

Alastair: next one is also a possible errata

Errata, glossary definition for "images of text" #264

<alastairc> https://github.com/w3c/wcag/issues/264

Alastairc: not using images of text SC limits intent of author for visual affect it seems that should be adjusted to remove a loophole.
... its question to those who were around when it was scoped?

Alastair: in definition 'in order to achieve a visual affect'

David: long arguments. if the designer had in their mind a particular design and devloper could only use images as text as acception
... if you can achieve design with real text need to do it that way
... if you can do it to particulary placed or a font couldn't get through CSS

Alaistair: that seems to leave a large loophole

<alastairc> SC: https://www.w3.org/TR/WCAG21/#images-of-text

David: whats the loophole

<alastairc> https://www.w3.org/TR/WCAG21/#dfn-images-of-text

Alastair: text that has been rendered in none text to achieve a particular affect
... text without affect, if its boring its not covered
... the definition doesn't cover standard text styling
... it doesn't seem to be covered

David: rather than is an add on. text is used to convey the information is the important point
... never seen that exception used
... don't have a problem with it, don't need to rewrite to make clearer

Alastair: other part the note creates a differnt loophole
... infographics graphs would be excluded

David: if photo of someone street sign wouldn't need contrast. incidental text would have been a better word
... incidental text like a sign in a window in a phot

Alastair: thats clearer to intent

David: painting drawing sketch, info graphics weren't very important at the time
... never heard that as part of discussion
... ok to clarify with wider culture. haven't had difficulty with this one but maybe others have

Alastair: andrew was main commmentor

David: notes on page or music score

<Jennie> Maybe like the lyrics on a page of music?

Rafal: someone playing music or looking a tscore

David: incidental possibly unless all people could see and use notes

Alastair: andrew struggling with webex
... it applies to 2.0 and 2.1, don't want to jump on it as a change with only five of us
... closing a loophole i haven't noticed
... doesn't include infographics i wouldn't have thought

<alastairc> Proposed change in the text: https://github.com/w3c/wcag/pull/777/files

David: i don't think it was original intent

Alastair: could do with a couple more comments form dissentors

from dissentors

Alastair: we need comments from others

<AWK> AWK: I don't see the benefit of this change.

RESOLUTION: On hold pending comments from people dis-agreeing.

<laura> +1 for waiting for awk and others.

<AWK> This is a normative change

<AWK> ok

Updating pause-stop-hide-understanding #778

Alastair: fairly straight forward, odd pharse that references 5 seconds and 3 seconds.
... almost editorial but wondering if there was something that came up 10 years ago that i don't understand

<alastairc> Original doc: https://www.w3.org/TR/2016/NOTE-UNDERSTANDING-WCAG20-20161007/time-limits-pause.html#time-limits-pause-intent-head

David: 2.2 more than five seconds in parallel with other content?

Alastair: no other mention of 3 secnonds

Andrew: 1.4.2 thress seconds is mentioned

Andrew Somers: 1.4.2 thress seconds is mentioned

David: arbitrary

Andrew: think it was arbitrary

Alastair: it helps to make it a few seconds from pull request
... if no one objections

RESOLUTION: Accept PR 778

Alastair: if not can accept pull request 778

DHTML roadmap techniques? #289

Alastair: note name roll value in roadmap

<Jennie> scribe: Jennie

<johnkirkwood> thanks

Alastair: Laura found it, and is happy to remove it
... any objections to accepting and just removing that comment?

RESOLUTION: Accept PR 779

Updating an example for buttons. #813

Alastair: issue #800 which David started around button backgrounds, and not having a border.
... during that conversation we discussed the process mostly from June 2018 just before publishing 2.1 to establish that buttons, links, etc. do not need to have a border or background
... that would differentiate. It would not be in scope if there was another means of identifying them.
... Somebody suggested adding that to the understanding document, with an example.

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

Alastair: which is in pull request 813.
... an edit in the table.

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

Alastair: Michael G responded he is concerned about the wording. He would be happier if it was changed to "A button which has **a distinguishing** indicator such as position...."
... affordances would probably be better achieved with another one.

Andrew K: a button such as an indicator does not need a contrasting outline

scribe: puts in the usability mention that will help clarify that technically you don't need it, but it doesn't mean it isn't a good idea.

<alastairc> "A button which has a distinguishing indicator such as position, text style, or context does not need a <em>contrasting</em> visual indicator to show that it is a button, although some users are likely to identify a button with an outline that meets contrast requirements more easily."

<alastairc> Jennie: Question - does it mean there wouldn't have to be a visual outline?

<AWK> @Jennie - see the buttons at the top of https://www.funka.com/

<Fazio> Contrast sensitivity is a major perceptual issue

Alastair: we had questions about that prior to publication
... there were different colors behind the main navigation
... the Funka example doesn't have any indicators around the main indicators - it is just text.
... seemingly clear designs were using other mechanisms, rather than a border or background.
... it is difficult because it is across all user controls
... there are some legitimate circumstances where there is not a indicator required.

<Fazio> I disagree

Alastair: there are other cases where a light indicator might be needed
... if you had a light indicator in some cases, and were suddenly required to have contrast, you would remove it.
... the intent of this SC was primarily around discerning inputs and controls, and knowing they are there in the 1st place
... there is an arguement for an SC around affordances

David F: I strongly disagree with that. Without a visual indicator, you will not know it is there.

scribe: especially for people with cognitive disabilities, this is really important

<johnkirkwood> agreed!

Alastair: did you have a look at the example that Andrew put in?

<johnkirkwood> tough on mobile too

David F: I don't have my glasses on right now, and I can barely notice the top navigation.

<johnkirkwood> I hace same issue as David

David F: I was searching around in the black bars, and then I figured out that there was no focus state change, so as I moused around I found it.

<johnkirkwood> I had same issue

Rachel: when we discussed it before publication, we talked about a possible SC for 2.2 on affordences. Are we still in a space where we could still consider this?

Alastair: yes.

<Zakim> AWK, you wanted to say that we are talking about an important point, but we can't change what the WG agreed to in this SC. We need to determine if there is a WCAG 2.2 change that

Andrew: yes. If there is something that we can determine that we want to suggest as a new SC, 2.2. is a time to do this, or Silver.
... the WG had an uncomfortable consensus, because that was all we felt we could do in 2.1
... I want to be sure we are not revising what the SC that we agreed to was, with changes

Alastair: yes. And, I think it is a good one to tackle, not an easy one to tackle.
... in terms of needing to go through a lot of examples, and agree on which examples are an issue, and from what perspective.
... this was primarily discussed around low vision, but it could also be cognitive perspective.

<AWK> https://www.w3.org/WAI/ would fail this also if the SC was interpreted that way

<johnkirkwood> its both COGA and low vision

Alastair: yes, worth tackling. It may be difficult to come up with examples that everyone would agree would work, but fit an easy to define guideline.

<AWK> and https://www.deque.com/ would fail too

<AWK> and https://www.nomensa.com/:)

Alastair: in terms of this particular example, which was an update to the nontext understanding document.
... does anyone have objections to the update as it stands?

Andrew: as amended with what I pasted into the chat?
... "A button which has a distinguishing indicator such as position, text style, or context does not need a <em>contrasting</em> visual indicator to show that it is a button, although some users are likely to identify a button with an outline that meets contrast requirements more easily."

RESOLUTION: Accept PR 813

<Fazio> sorry

<Fazio> I object

Andrew: David F are you objecting because you feel the SC says something different? Or because you feel like the change is not reflecting what the working group agrees the SC was.

David F: I think you shouldn't remove the identifying features of a button for any purpose. Does that make sense?

scribe: a visual indicator.

Andrew: do you feel the language of WCAG supports that?

David F: I would need to do more research on it.

Alastair: current situation: SC for non-text contrast does not require people to have a visual indicator. There is history.

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

Alastair: Glenda had some similar comments and missed that bit of history as well.
... the history is now in the github thread. This is a good place to read the history.
... I don't think the objection applies to the change.
... the requirement is something we need to have in the SC.
... Rachael will bring this to the COGA group to discuss.
... we will let the resolution stand. And will continue this conversation.

<david-macdonald> I've just created https://docs.google.com/document/d/1WhZAbswvPHs7A3stfqM_ATsaBHPeGbHtARcmaKMck1U/edit?usp=sharing

Alastair: I will add to the WCAG 2.2 stuff.

Techniques dashboard

<alastairc> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=0

Alastair: a quick review of the techniques for 2.1 spreadsheet
... we have sufficient techniques for all except 3 of the WCAG 2.1 criteria.
... missing one for time outs, target size, and ?
... and current input mechanisms

Andrew: Patrick had some going

<david-macdonald> I just changed the permissions... If you had trouble try again.

Andrew: the group wanted to prioritize the single and double A ones first
... if people are looking for priorities. Looking at the failures for the A and AA
... is where we need attention next.

Alastair: it is also where we have less drafted, so it is a cleaner slate
... text spacing, content on hover or focus

Andrew: identifying purpose and reflow
... Mark did you sign up for one recently?

Mark: it was one of those

Andrew: I highlighted it in blue on the first worksheet
... are you still able to work on that?

Mark: yes. Or Mike.

Andrew: should be fairly easy.

<johnkirkwood> sorry need to drop

Alastair: Can anyone else put their hand up for a half hour to 1 hour work over the next week or 2?

Andrew: I would suggest an hour or 2

Alastair: we do have templates for these type of things.
... you can draft it in a Google doc if that is easier.
... if you want to go straight into github, that is fine.
... just fleshing out some of the documentation we need.
... ok. Feel free to get in touch by email if you don't want to speak up right now.
... that's the end of our agenda.
... any questions about things we are working on at the moment?

Andrew S: re a possible SC we are working on in Silver right now, in terms of visual contrast.

scribe: what would be the first step to potentially add on an SC to 2.2?

Alastair: you could give us an overview now. Then, draft a Google doc, and we put it in the cue

Potential new SC for 2.2

Andrew S: 1 of the things we are working on has to do with perception of contrast.

<Fazio> I was looking for fyi agree

scribe: mostly body text - the way we perceive it is at the far end of our ability to perceive it
... due to spatial frequency
... we are providing some use cases in terms of required contrast.
... the potential SC would be a stepping stone to Silver.
... for body text, or columns of text - 7:1 instead of 4:1
... this would be in keeping with other worldwide standards.
... when we say 7:1 is comparable to 10:1
... ISO standards reference 10:1 which would be similar to WCAG's 7:1

Alastair: that sounds reasonably easy to define and add to the specs.
... yes, I will email you a link to the resources for creating that issue.

Andrew S: great!

Alastair: I would appreciate your feedback on some questions about focus visible success criteria, the updated version of this.
... it is around change. Our current is around adjacent colors.
... if you know of any research that could contribute, that would be greatly appreciated.

Andrew S: yes, will do.

Alastair: any other comments?
... we will give you back a half hour. Have a look at the techniques spreadsheet, and see if there are any you could review, and do a failure technique.
... please email me in case someone else is doing one at the same time.
... Thank you
... I will be back in 3 weeks.

<alastairc> rrsagent make minutes

<alastairc> trackbot end meeting

Summary of Action Items

Summary of Resolutions

  1. Accept PR 767 ammended to keep F26
  2. On hold pending further comments
  3. On hold pending comments from people dis-agreeing.
  4. Accept PR 778
  5. Accept PR 779
  6. Accept PR 813
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/08/13 16:34:18 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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)

Default Present: AlastairC, AWK, Fazio, Raf, Jennie, JustineP, MichaelC, johnkirkwood, Laura, KimD, jon_avila, david-macdonald, Rachael
Present: AlastairC AWK Fazio Raf Jennie JustineP MichaelC johnkirkwood Laura KimD jon_avila david-macdonald Rachael
Found Scribe: johnkirkwood
Inferring ScribeNick: johnkirkwood
Found Scribe: Jennie
Inferring ScribeNick: Jennie
Scribes: johnkirkwood, Jennie
ScribeNicks: johnkirkwood, Jennie
Found Date: 13 Aug 2019
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]