W3C

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

21 Jul 2015

Agenda

See also: IRC log

Attendees

Present
Laura, Louis, Makoto, EricE, Kathy, MoeKraft, marcjohlic, David_MacDonald, Mike, Elledge, Katie_Haritos-Shea, MichaelC, kenny, Joshue, Wayne, Wayne_Dick
Regrets
Chair
Joshue
Scribe
MoeKraft, Wayne, David

Contents


<trackbot> Date: 21 July 2015

<Kenny> agend+ Review of progress on Github issues https://github.com/w3c/wcag/issues

<laura> https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<MoeKraft> Scribe nick Moekraft

<laura> Scribe: MoeKraft

WCAG meeting schedule reminder - there will be no meetings on 28th July, 4th August.

Josh: On holidays. Will reconvene second week in August

Review of progress on Github issues https://github.com/w3c/wcag/issues

Joshue: We have a few folks who have made progress. Laura and Wayne.

Laura: I have some proposed text for issue 105.

Joshue: Is this ready for survey?

Laura: Do not have permission to mark it ready. But yes, this item #105 is ready for survey

Joshue: Thank you Laura
... Did that go okay.

Laura: Yes

Joshue: Wayne, how about you?

Wayne: Item #78 was a general issue on low vision. It will be a great thing to bring up but we can table for now. Take a look at my comments.

<laura> https://github.com/w3c/wcag/issues/105

<laura> 105 is ready for survey

Wayne: Itme #95 regarding Contrast for graphics could be turned into a technique. Let's send around on a survey
... Action images with good contrast will be usable without being disruptive. This is a good technique. A lot harder to change than text on a background.

https://github.com/w3c/wcag/issues/95

Wayne: Can we send this out as a survey.

Joshue: Yes. If you can write up technique we can send out to the group.

Wayne: Pretty clear what issue was
... https://github.com/w3c/wcag/issues/103 is on Situation B. We do have ARIA techniques. My question is do we put forward the 23 techniques from the WG or are we particular and go to task force and go through these 1 by 1?

Joshue: Not aware of subgroup in Protocol and Formats. We did have an ARIA task force which will be revitalized soon.
... We will aggregate all techniques under one umbrella and identify which are advisory

Wayne: Situation B deals with Roles, Should we go ahead an suggest ARIA techniques which are pretty well defined. I think we should.
... I propose we put ARIA techniques in 4.1.2

Joshue: Go ahead. Whatever you see fit.

Wayne: Will do. And will send that out.
... How do you compute contrast with a gradient background? I think we should go ahead and publish as a technique.

Katie: Pick the lowest contrast and compare against that

Wayne: That's what we generally tell developers to do when we audit them.
... I will write this up in technique language

Katie: On a moving background usually an image, you want to test on a logical stopping point.

Joshue: Anything else?

Wayne: Stylistically, I should put this in a couple techniques to make palatable so we don't have a 7 part technique.

Katie: I already have some stuff written up

Joshue: Any other comments for Wayne? Thanks Wayne.
... Mike Elledge

Mike_Elledge: Mostly wanted feedback on what I put into GitHub in response to one of the issues is helpful. Issue # 102

https://github.com/w3c/wcag/issues/102

Mike_Elledge: Situation when there is a refresh, auto redirect rarely provides information why the page is being redirected. Suggested this violates WCAG 2.2 but really WCAG 3.2 Change in Context
... Before someone initiates an action, they are not told what will happen. If pressing a button takes you to a different page or website. I think 3.2 fits better with this rationale.
... How do we best show this in WCAG 2.0? This should be a failure when the user is not informed of the auto-redirect

Katie: I don't limit to one. 2.2.1, 2.2.2, 3.2.1
... 2.2.1 time limit, 2.2.2 really just basic when content is moving causes disorientation, 3.2.1 change of context

Mike_Elledge: Do we choose multiple checkpoints for a failure?

Joshue: Put under all relevant success criterion

David: 3.2.1 is on focus, is the page a component and is it receiving focus.

Katie: It's hijacking focus

David: It's making it not possible to receive focus.
... Not sure we should map to 3.2.1, for example, if you tab forward and moved to a new place is what I think 3.2.1 is about. What is the summary of the issue?

Mike_Elledge: Auto-redirect with no information provided, browser prevents it.

David: Right user does not know where to go
... If the browser stops the redirect, everyone is punished equally

Joshue: Change of context here

<marcjohlic> +1 to what David is saying

Joshue: This would be something to note in your GitHub issue

David: Usually a result of input or focus trigger the the change of context. So how do we map auto-redirect to one of these?

Katie: Usually someone clicks to go to a new page

Mike_Elledge: Someone clicks on a link. Give message: This will take you somewhere different.

David: This is not necessarily on the page.

Katie: Don't stick with page by page,

David: May not be on their own website. I really want to fail this just unsure of the mapping

Joshue: This is an interesting discussion. There might be a 1 to 1 mapping. Mike, do you have enough to crack this issue? If not 1-1 but spread over a few SC. Are you any wiser after discussion?

Mike_Elledge: I thought information be provided up front, but if interrupted, then this is another point where we should receive info. I would call it a failure on all 3 success criteria.
... But also acknowledge David's concern about not being on a page

Joshue: Anyone else?
... Please use mail list if you have any questions
... Eric, are you on the call?

QRG Updates with Eric

<yatil> http://w3c.github.io/wai-wcag-quickref/

Eric: Thank you. Just a quick update on the Quick Reference. I have worked a bit on this over the past 2 weeks.
... Look at left navigation menu on larger screens. Can access filters pretty quickly. Result of feedback session.
... Wanted filters more in focus for quicker access
... Got all the left navigation and with prominence and position should lead persons to appropriate filters.
... Second change, success criteria layout. Now more spacious.
... Thoughts to make it more distinct. Orient more easily.
... Compact view of the success criteria. Button is positioned to the right.

<Ryladog> Looks very nice Eric!!

Eric: Third change, Techniques layout, 1.1.1 e.g. to show techniques for this criteria you now have checkboxes to show and hide content and compact the view
... On left in filter column we have built in possibility to select techniques e.g. advisory techniques & failures or technologies, can change on individual success criteria
... Much easier than before
... Other minor changes, top notification bar, people will be notified when they change the filters, could be more prominent
... Also minor editions to styling
... Will work on Mobile browsers

<yatil> http://w3c.github.io/wai-wcag-quickref/issues/

Eric: IF you have any comments or questions speak up now or look at issues on GitHub or create new ones

<Wayne> q

<yatil> https://github.com/w3c/wai-wcag-quickref/issues/new

David: I really like it
... Question about choice on tabbed interfaces
... When you select content and hit tab key the next stop is filter and then contents. With tab stops should take you inside content.

Eric: No conscious decision right now.
... We want some consistency. Filter first and then content. Since it is short navigation it should be fine.
... If we use ARIA and make it clear things have changed

David: I like what you've done but there is definitely 2 camps on whether to use tab or arrow keys

Eric: We have to think about desktop metaphors from the Web as introduced by ARIA. Use ARIA to show it's a menu. You basically have to adopt the arrow key functionality as well. Need to use JavaScript from ground up.
... Can get very messy. This simple approach shouldn't be a problem if we communicate clearly.

David: Any one else have opinions on this?

Joshue: Several blind uses I know do not understand the tabbed interface metaphor. Maybe not a successful pattern.

Wayne: I know that in a lot of schools for the blind in the US, they focus on using the arrow key in preference to the tab key. So yes, it is a problem.

David: My understand is that you are moving down the page using the arrow key,

Wayne: In practice, there are other ways to use tab key and children are not being trained to do that. This is what we ran into when we did accessible high stakes testing. Alot of folks are trained to depend on arrow key.
... It's a difficult problem

WCAG Extension discussion

<yatil> Scribe: Wayne

Josh: Extensions: 3 Points of Interest in IRC

<MichaelC> - can extensions modify WCAG 2.0 SC

<MichaelC> - must conformance to WCAG plus extension be backwards compatible with WCAG without extension

<MichaelC> - can extensions conflict with each other

Josh: Should extensions modify existing criteria.
... Identify extensions that can be done through success criteria.

Michael: question of whether the WCAG + extensions is backward compatable

David: Extensions should add to WCAG not decrease WCAG difficulty.

<laura> +1

MichaelC: Questions are interrelated. Changing WCAG may change. Should we just add or change. Can we override existing criteria.

Josh: Can extension WCAG.

David: Yes

<David> Wayne: Important issue, what we consider A11y support. Screen Mag is not sufficient a11y support

<David> Wayne: so WCAG has nothing apart from that for a11y

<David> Scribe: David

Wayne: can't navigate the DOM with magnifier
... SC work 2 ways ... 1) AT 2) does it exist

Michael: A11y support... if there is no tool we can't have a SC

Wayne: proposal to merge WCAG and UA WG, approach armonized

Michael: but fr us, if there is no tool we can't donanything

Joshue: It's an assistive technology issue

<laura> Wayne: Responsive design will do the job. It is the AT for low vision.

Wayne: AT exists, ...
... Responsive design is an AT

Michael: well that is not AT, it's a technology technique
... there may be candidate techniquesto require...

<scribe> scribe: Wayne

Josh: There are two other issues

<MichaelC> to clarify, I am saying responsive design is not an AT, it is an authoring technique - but its existence means there are ways to meet the SC, so we´re back in ¨accessibility supported¨ territory

<MichaelC> and therefore can have a reasonable authoring guideline

Josh: Second question must conformance + the extension be backwards compatible with WCAG

<Ryladog> +1 to Davids proposals

<laura> +1

David: Extensions must be harder so backwards compatibility holds. We can make conformance harder not easier.

MichaelC: Do we support backwards compatible. Is it a goal.

Josh: An extension by its nature may not be backwards compatible. If it addresses some new need.

Laura: Unless there is some thing we are not think of at this time.

MichaelC: Example: Provide multi media but don't privide alternate text.
... this would nullify alt-tex.

David: That really gets in the way. A show / hide model . Nothing can interfer with conformance.

+1

<laura> WCAG is a prequisite to extensions

David: Extensions cannot invalidate WCAG.

Josh: Can extensions conflict?

David: No. Success Criteria conflict.
... We cannot have them conflict with each other. Techniques that cannot can manage conflicting needs.

MichaelC: We might run into extension A is important and extension B will break us. We need to be careful.

Kathy: Agree in principle in stable WCAG. What change priority level. Can we change the priority level.

MichaelC: Using the metric harder extensions only.

sorry Michael I got lost.

Makoto: The next japanese Standard (JIS) will be the Japanese translation of WCAG 2.0
... I'd like WCAG 2.0 to be stable. However, once and extension will be published, we (JIS) might need to do something for the international harmonization.

Mike_Elledge: It will be helpful to provide context for the extensions with respect to how it sets with WCAG 2.0

Katy: Change priority could change WCAG.

Laura: To avoid conflicts between extensions. Have all extension groups coordinate extensions.

<laura> Avoid conflicts between extensions. One idea: each TF could review all other extensions.

Josh: We must put these comments on the survey. Could these 3 issues be converted to principles.

<marcjohlic> trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/07/21 16:36:28 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/id M/id_M/
Succeeded: s/issue 5./issue 105./
Succeeded: s/Scribe:nic//
Succeeded: s/Scribe, Nick//
Succeeded: s/Wayne Dick/present+ Wayne Dick/
Succeeded: s/ne D/ne_D/
Succeeded: s/the WCAG/question of whether the WCAG/
Succeeded: s/Extnsions/Extensions/
Succeeded: s/MichaelC/David/
Succeeded: s/eric... where is the github issue list for the how to meet...//
Found Scribe: MoeKraft
Inferring ScribeNick: MoeKraft
Found Scribe: Wayne
Inferring ScribeNick: Wayne
Found Scribe: David
Inferring ScribeNick: David
Found Scribe: Wayne
Inferring ScribeNick: Wayne
Scribes: MoeKraft, Wayne, David
ScribeNicks: MoeKraft, Wayne, David
Present: Laura Louis Makoto EricE Kathy MoeKraft marcjohlic David_MacDonald Mike Elledge Katie_Haritos-Shea MichaelC kenny Joshue Wayne Wayne_Dick
Agenda: https://lists.w3.org/Archives/Public/w3c-wai-gl/2015JulSep/0077.html
Found Date: 21 Jul 2015
Guessing minutes URL: http://www.w3.org/2015/07/21-wai-wcag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]