Accessibility Guidelines Working Group Teleconference -- 14 Mar 2017

<AWk> +AWK

<AWk> Scribe: Lisa Seeman

<alastairc> +alastairc

<laura> +Laura

<KimD> +KimD

<neilmilliken> what is the webex password please

ACTF FPWD Reminder

<Lisa_Seeman> scribe: lisa_seeman

first public working draf for the testing framework

we need to approve it

<marcjohlic> Does anyone have the ACTF FPWD link available to paste in here?

<Wilco> link: https://w3c.github.io/wcag-act/act-framework.html

<marcjohlic> Thanks Wilco!

<Rachael> https://www.w3.org/2002/09/wbs/93339/ACTFrameworkFPWD/?login

undoing bruces regrets (all is forgiven)

any questions on the acf survey?

Thursday call option

this is an optional call to work out proposals

adress wording etc

<Rachael> Lisa: I'm for adding a call time. Two things we need (maybe seperately). 1. We need a working session to work on wording, but this isnt' the best forum for it. This is getting on top of the user case and addressing the needs. Maybe invite people outside the task force. 2. Review categories of user needs with the working group. Discuss it and provide context. Examples (Perssonalization).

<Rachael> Lisa cont: Maybe more educational. There would be an advantage in doing that. Not a technical converstaion. This is a seperate track to help people understand the user. There is a lot of learning to do around user needs.

<Rachael> AWK: Do you think that can't happen within the call? What if we dedicate the first half hour of the call to understanding? Is that not enough?

<Rachael> Lisa: We could. Maybe we should do that in an hour but there are so many topic that I'm concerned that once a week isn't enough.

michael: we are already asking a lot

<JF> +1 to MC

<jamesn> +1 to MC - there is already a lot of other non WCAG things to look at the first half of this year

<Rachael> Lisa: I'm concerned about timeframe. If people want to work on the topic, than they can go to one call but if they want to know about the topic then they could go to that call.

<Rachael> The task force is responsible for helping the working group understand the topic. People on this call want the expertise as well. I'm not sure we can do that in a call once a week.

we can ask what people prefer

<scribe> scribe: lisa_seeman

<Rachael> Michael: I hear that point. I'm not sure people will attend a call that is only an education session. I want to be sensitive to how much we ask of people. We could also ask people to read a paper.

andrew: we are probebly asking as much time as we can

<Wayne> +1

katie agrees

let us see how it goes

alastair: have smaller group sections in parallel

we dont need everyne to attend everything

<shwetank> +1 to alastair's suggestion

but we can have subgroups working on an issue

wayne simpathises but agrees with michael . what lisa is saying is that with wcag 2 we new the matirial and how it fits together

but now we just look at the sc's and how it all works is not understood by the group

I can also support alastair´s version of the suggestion

(it is what I had in mind)

michale is ok with alisters

add hock when more is needed by the working group when called in by the sc manager

andrew: we will identify this thursdays call in the last ten minets today

please pencil in the time

11: 30-12:30 ET

same password as this call

GitHub document structure and process proposal (https://github.com/w3c/wcag21/tree/structure_proposal/guidelines) (10 min)

This has an sc directory and terms diretory

index is the main file with include files for each sc and glosary

in each of thought there is a sub drectory for wcag 2.0 and wcag 2.1

labled 20 and 21

in ech on is the section element and included pagraphes

and there is a raw git page for each one

<alastairc> +1 to this, but would like SC managers to open a new issue before the next public draft.

we may need a document to link to the raw git for each of these

but we have discusions on the issue on github

Michael: and they link to the github version of the sc

john f. many sc in the directory - is this als for post 2.1

andrew: maybe

john f. likes having them all in pone place

mike: good process but langage on proposed
... sperate out proposed and other stuff

michael: hard to do stile on snippits

katie: all i can do is 2.1

all i can see is 2.0

michael: i see them both

<Rachael> scribe: rachael

Lisa: If at the top of each issue, include the latest proposal in bold and another link to the original proposal. I suggest an ask to the COGA list that this is workable and if not discuss it on the call.

Michael: I've already asked the entire working group. I'm willing to give it some time. I Can ask the task forces seperately if people feel its needed but the longer review cycle, the longer this takes.

<marcjohlic> +1

<AWk> Michael's email: https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/1166.html

Lisa: I will take an action to follow up with the task force. I think a lot of the COGA members are a bit quiet. Can people put a +1 since many are on this call?

<neilmilliken> Well you know I have real issues with the platform

Lisa: Lets see if we can get COGA people to participate.

Michael: What is the timing? I can't do anything more until I get an approval.

<neilmilliken> the approach is fine the platform is not

<Lisa_Seeman> scribe: lisa_seeman

<Rachael> Michael: I know this is still not perfect but I believe its much better than what we've been doing. If you object, what would be better and achievable?

<Rachael> scribe: Rachael

<neilmilliken> sorry lost connectivety

Lisa: Suggestion - I spoke to the guys from Google about Google Docs accessibility issues. They wondered if people were aware of accessibility mode. I'm not sure if using that mode if Docs is usable, but that would be the better way for the COGA taskforce. Each issue as a Google doc.

<kirkwood> +1 to Google Docs

Michael: Google Docs won't let us maintain source code. We still have to deal with GitHub. We'd have to duplicate. We can do that but we'll still need a version in GitHub but if people prefer taht we can do that.

Lisa: IT woudl then fall on the editors vs the task force members.

<Lisa_Seeman> scribe: lisa_seeman

wayne" cna we strip off the sc without the code

michael: yes via rawgit

<EA> I have made it - We would prefer to have text being accessible in Google doc or a wiki that we could then transfer into Github where the experts can cope with the code?

wayne: at 200% magnification it cuts off

<marcjohlic> RAWGIT LINK https://rawgit.com/w3c/wcag21/structure_proposal/guidelines/sc/21/accidental-activation.html

<AWk> for example: https://rawgit.com/w3c/wcag21/structure_proposal/guidelines/sc/21/accidental-activation.html

andrew: check the url is rawgit

wayne will figuer out the links

mike: some companies miught not let google docs

not sure if that is commen

<Zakim> alastairc, you wanted to ask The comments aspect is what's needed, I don't think Google docs supports public comments well?

or relivent

alister: how do people coment

<Rachael> scribe: Rachael

Lisa: When we did the rewrite of the success criteria, each one went through multiple rewrites. We created headers and people added comments under each header.

<Lisa_Seeman> scribe: lisa_seeman

ea: there is a coment system

and the coga group would use wiki

michael: one of the problems is the multiple places

it needs to be one

ea: she was not suggesting all three

michael: we will need some github

ea: some people will have to ask for help

and we wll need a two tear system

<Jan> The problem with the GitHub comment system seems to be that it's not easy to track final wording, so it's difficult to know what you're actually supposed to review.

michael: the comment system is not cuseing issue

but yes this may lead to a two tear system

ea: we lost a lost of comments

john k.: i have ben playing and working with this a lot with my disability and my work. the good thing with google docs, it is colabritve, the history is recorded and can be done pre any uploading and forking on github

it will make things much easier , but at least using it at the begining pof the proces will be hugely helpfyl

john: google docs is very helpful - you can see the origial version and threads, and i would be happy to explain how to use it

marc: the main issue was reading the code, and this is solved via raw git, so please check that you see how much easier it is

(lisa thinks people know that)

wayn: raw mode loses indentation

lq+

andrew: rawgit might be ok on this

<marcjohlic> https://rawgit.com/w3c/wcag21/structure_proposal/guidelines/sc/21/accidental-activation.html

marc: raw is just the name of the company it is not the raw button on the code page

neil: it is better but the manigmanet and so on is a problem

andrew: no more pull requests - just review the rendered version and issue

<Rachael> scribe: Rachael

Lisa: The issue people had in GitHub Issues is that the comments are hard to follow. People make a comment and then there is a new draft of the wording so the comment isn't relevant any more. There is no way to know which comments relate to what version, what comments were applied and what comments people agreed with.
... It is harder to add a comment. Following and tracking is difficult. Its hard to manage the threads that are going to get even longer than they are now. Difficult to tell what is outstanding. If we want COGA experts to review it, we are buying into a format that doesn't support them.

<Lisa_Seeman> scribe: lisa_seeman

michael: you can do it, but it is hard

marc: maybe all the fetures are not being used

emogies and labelings and assining

andrew: we do not have consnsus

lisa will mock somthing up

Survey of SC Proposals: https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results (15 minutes each maximum)

clear controls

neil is here

neil is happy to use the word unabigues

inplace of clear

mike: things should be normalized for ovelap before tit comes to survey

very hard to deside what is standard

see his comment in github

and it is all about people using something enough to learn

that meens use afordences

athers just need to be constacting role and the rest is personlization

not author responcibilty

auther: should be contrast for the first one

<Glenda> +1 to removing color contrast fromt his SC (because it will covered by 1.4.14 User Interface Component Contrast (Minimum))

andrew:

standard stypleing

and what ius standard 5 years ago is not standard today

neil do you want to take this?

<Glenda> +1 need more time to answer survey

<jamesn> +1 to that

john f. to hard to respond to all the feedback

we need more then 48 hours

<Rachael> +1 to difficult to get through all of it

Andrew: also finds it hard

<Rachael> scribe: Rachael

Lisa: We need to get personalization off the ground. That will be the preferred way. We are trying to have 5 tested values for personalization structure. If you've marked things as a role and the personalization architecture is off the ground (which it should be), then you are good to go.
... If it doesn't work with the 5 recommended values for personalization then you mayhave failed, because there is a standard for making it work.
... We will be making templates. So that is the preferred way. The other option is to use the standard visual pattern. If you are using standard HTML, then you don't need personalization. But if you want to use your own designs, we aren't blocking you but you need to use personalization.
... The timeline for personalization is in line with WCAG 2.1
... That should be ready to go.

AWK: You are talking about the personalization support in ARIA which is still under development. If you have a technology that doesn't support ARIA such as a native mobile app, the success criteria would be saying you have to use standard controls.

Lisa: Or support personalization as well. We will need to define standard controls very well. It has to be patterns. Like the ARIA working group author techniques.

AWK: But this is not the personalization success criteria. This is the clear controls succes criteria.
... Should this be bundled with the personalization success criteria? We need to make sure the criteria is technology independent.

Lisa: You can check it works. That is one aspect. Even if you have done personalization. If you are on a platform that doesn't support personalization, then the controls need to be clear.

<Lisa_Seeman> wayne: if you go far out enoguh then you have to take responcibilty as an ather to make sure it is supported

<Lisa_Seeman> mike: current success crteria cover what you are asking for

tsarget size

target size

<JF> I have not submitted my survey results, but there are concerns here, so "6" have issues (and perhaps more)

<Lisa_Seeman> andrew: problem with implementability

<Lisa_Seeman> percribin a size would make the permer links to fail in wcag 2.0

<Lisa_Seeman> kathy: there are exceptions

<Lisa_Seeman> there were two alterntives, including having one dimentions

<Lisa_Seeman> also we are saying there is one way to do the key functions

<Lisa_Seeman> andrw: unless there was a way to represent wcag 2.0 it would fail

<Lisa_Seeman> kathie: there are ways you can dress that unless there are two links next to each other

<Lisa_Seeman> john f: is this grafics only?

<Lisa_Seeman> how does an evalutor know whet the pointer input will be of the user

<Lisa_Seeman> what about a rubber tip pen

<Lisa_Seeman> james: how do your define primary functions

<Lisa_Seeman> also sees conflicts

<Lisa_Seeman> mike: this is aimed at touch affordences

<Lisa_Seeman> what about mobile?

<Lisa_Seeman> and trying to apply it to desktop

<Lisa_Seeman> when it is about apps for mobile or at least mobile

+1 to finding a way to specify interface that support touch

<Wayne> 44/16= 2.75 em, 22/16= 1.375 em

<Lisa_Seeman> maybe strip it down to represtn thea

<Lisa_Seeman> wayn: we are just asking a minumm size and desgn around it

<Lisa_Seeman> why is it so har

<Lisa_Seeman> mike: what about a foot note as a superscript

<Lisa_Seeman> wayn - well i can not hit them

<Lisa_Seeman> unless i magnify them

<Lisa_Seeman> james: and we need to balance them

<scribe> scribe: Rachael

Lisa: People with dimensia or who are older are fantastic on their topics but learning new tools isn't going to happen. Even if Wayne is savvy enough to know he can tab to it or zoom it, there are still people who that will be a barrier to. Its a barrier because of a disability - the ability to learn has slowed down.

<EA> +1 to Lisa comments - it is a nightmare when trying to train us oldies on new things!

<Wayne> +1

Lisa: You can't always assume people will be managing to learn new tools.

AWK: Are we OK to talk about these two on Thursdays?

Lisa: Encourage people to read Neil's issue paper on clear controls. He isn't available on Thursday. Can we discuss personalization?

Its a crux issue.

<alastairc> Seem orthogonal to target size though.

Andrew: We'll talk about personalization and target size on Thursday

<dboudreau> thanks all!

<gowerm> +1 " Seem orthogonal to target size though."

<laura> bye

<AWk> trackbot, end meeting

- DRAFT -

Accessibility Guidelines Working Group Teleconference

14 Mar 2017

Attendees

Contents

ACTF FPWD Reminder

Thursday call option

GitHub document structure and process proposal (https://github.com/w3c/wcag21/tree/structure_proposal/guidelines) (10 min)

Survey of SC Proposals: https://www.w3.org/2002/09/wbs/35422/March14SCReviews/results (15 minutes each maximum)

clear controls

tsarget size

target size

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output