Web Content Accessibility Guidelines Working Group Teleconference -- 31 Jan 2017

<KimD> +KimD

<AWK> Scribes needed: https://www.w3.org/WAI/GL/wiki/Scribe_List

<AWK_> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

preesnt+ jeanne

<scribe> scribe: jeanne

Welcome to AGWG

Josh: Welcome to the Accessibility Guidelines Working Group. We have a charter for the next couple years. Yay!

[cheers]

Josh: we are going to make a few changes, like our IRC channel. We will get in touch with those logistics.

SC review process discussion

Josh: Success Criteria review process needs to be communicated better to the group. Not to spend too much time on it.
... there is some confusion about the process.
... We have an intermediate review process
... then we have a "end-type" review when the success criteria is ready
... also when to submit a pull request. Only pull request after the success criteria is ready for review
... havign a lot of pull requests with multiple commits is confusing. Then future comments should go there.

<Joshue108> good point

AWK: There are some nuances. It is ok to have multiple commits as long as they are on topic. For example, a commit for a SC can be bundled with a commit for a glossary item. That's ok for a pull request.
... the point is that the pull request needs to be focused on the changes to the guidelines document, not the Understanding document and other changes

Josh: The cleaner the commit and the pull request, the better. It can be difficult to pick through multiple commits to find the meat of the success criteria.
... I want the SC Managers to let the chairs know when the SC is ready, or if the SC is at a "crunch" point.

JohnR: I have a lot of feedback on my SC, and I will go back to incorporate it. How do I handle it when I have a new version?

Josh: You can put your new version in a new issue, and reference the older version. Github has features that can help you do that to reference the older version. Then create a pull request.

JohnR: Is it ok that it has a new number?

AWK: There will be edits on that pull request. You can go into Github and edit it, and push it forward again. I think it will be difficult to change the numbers. You still have your branch, and you can edit your branch.

<Zakim> AWK_, you wanted to say please don't create a new issue

<Glenda> I’ve been using the LVTF wiki to draft my changes. Then I meet with the LVTF and get their approval. Then when we have consensus…I have Jim Allan update it on github for me. I don’t know if that is the best way…but that is what I’m doing.

AWK: @@AWK, please reiterate your directions@@

Josh: Agree, that we will do the editing in the existing Github issue

<AWK_> AWK: I think that when a pull request is commented on and needs changes, the SC manager should make the changes and resubmit the pull request.

Glenda: Perhaps I am being too careful in not creating too much noise. I am working on the visual contrast issues, there is a lot of back and forth. I am working on it on the LVTF wiki, and when I get consensus, then I move it back into Github. Is that ok?

Josh: I mostly want to do what works. The advantage of Github is that we have a thread of comments to follow. The disadvantage is that we have comments in one place.

AWK: It is valuable to have the comments. It is useful to bring it back to Github as often as possible because we want to have it all in one spot.

Laura: What's the best way to merge issues? We are talking about merging 74, 78, and 79.
... we are merging them into one SC

AWK: When you create the pull request, put in a link to all the issues it came from.

<laura> https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Ability_to_Override

Josh: You are creating a new Success Criteria and closing the existing ones.

David: Close 74 and 79 and keep 78 open.

Laura: I don't own them all.

<AWK_> AWK: right, issues might be merged before a pull request is made, or _as_ a pull request is made.

David: request that the other managers close their issues

Update from SC managers

JamesN: I would appreciate some visibility of what is coming in the next week, so I can get other people to look at things.

+1 to more advance warning of what is coming

<KimD> +1 to definitely needing more lead time of what is coming

JamesN: I would like a week's advance knowledge so I can get input about others.

AWK: I don't know that we can promise it, but we can try. WE are in a time crunch to get published. We want to get heads-up from the people who are managing SC for more advance notice. WE have a lot of discussion, but not a lot of advance notice.

<JF> +1 to jamesn as well

AWK: I appreciate the concern and share it.

<David_MacDonald> I think we're ready with this https://github.com/w3c/wcag21/issues/2

Josh: Surveys will be open. If something comes out next week for a certain time, people can look at them and bring them to their teams.

<Kathy> https://github.com/w3c/wcag21/issues/59

Kathy: One of the mobile ones we submitted on issue 59, we have consensus to defer that to Silver. We will revisit in Silver.
... a lot of the mobile SC we submitted are around keyboard. Pointer has brought up a lot of questions and we need to address them in Silver.

<Glenda> +1 to defer to silver

Kathy: no one has picked it up to manage it, so I am bringing it forward

<David_MacDonald> +1 to defer

<Zakim> JF, you wanted to confirm that FPWD is also a good time for wider review

JohnF: I want to follow up on JamesN comment. The FPWD is an opportune time for wider review. My plan was once we had a FPWD to then collect more comments internally and comment then. I'm concerned about signal to noise
... it is a firehose of information. I'm trying to stay on track of the relevant things, and wait for a stability point to comment.

Josh: What we really want to talk about now is glaring errors. There is some vetting done by the SC Managers and the Task Force.
... once it is published, then we will look at it in more detail.

JohnF: There are a lot SMEs in Deque, and I want to gether them around and submit a coordinated response. Many people whose feedback is valuable and useful

<Joshue108> JS: Returning to Kathys comment..

<Joshue108> JS: I would not like to see important SCs defered..

<Joshue108> JS: When a mod to an existing SC in 2.1 could address the issue.

<Joshue108> JS: It thought that the pointers were a good example of making a change to an existing SC.

Kathy: we have existing success criteria that are complex with a lot that needs to be considered. There is a lot in keyboard and carefully thing about.
... I agree with Jeanne, that if we make changes to existing SC, that would address some of it, but the Working Group had said that we would not make changes to existing SC.
... if we can't make changes to existing SC, then it would have to be deferred to Silver.

<Zakim> MichaelC, you wanted to explain FPWD process and to say we shouldn´t be deferring anything to Silver yet and to address delta SCs

Michael: It's way too soon to defer to Silver. That should be at the end of the process
... in regard to delta success criteria, the decision was not to change existing SC at the beginning.
... I would suggest that you put in a delta success criteria, with details of how it would work with combining with existing SC.
... the decision should be made later when we have everything in front of us.
... the FPWD has nothing special about it. We can publish new drafts every day if we want. There should be key review points, and let people know that a draft is ready for wide review.

JohnF: Once we have a FPWD, I thought we couldn't add more SC?

Michael: No, we can continue to add SC.

JF: then when should we have wide review?

<Glenda> For me, I see defer to silver logical when there are conflicts in solutions needed by different types of disabilities. (and this may not apply to what Kathy brought up…but I’ve seen decisions in LVTF where we logically defer to silver due to conflicts in different needs of different types of disability)

Michael: I think it should be more toward the end of the year.

Josh: We don't want to publish everything. We want to do some weeding at this point, but we want to the world to see the work we have been working on for years.

<Glenda> https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1#Version_3_Changes_.28Jan_29.2C_2017.29_Incorporating_Comments_Round_2

Glenda: I have changes with Issue 10 Color Contrast.

<Joshue108> https://github.com/w3c/wcag21/issues/10

Glenda: this is documented on the wiki, the most important thing is CSS pixels, and adding reference to the CSS pixels that Alastair did on Issue 9
... there is an example of icons, that were causing issues, so we m oved them to issue 9

<Zakim> laura, you wanted to say Animation from interactions #18 has consensus from the people participating in the issue. Pull request is ready.

<laura> Pull Request: https://github.com/w3c/wcag21/pull/96/commits/ad8b5f43f707aa58d9257197d33a4b48b035dd0e

Laura: Issue 18 is ready to go for next time, so I will make a pull request.

<Joshue108> Thanks Laura - do pull PR URIs into the Notes and Status section of the SC managers page

David: Going back to Kathy's issue with 59. We need to be able allow ourselves to retire things. We thought in the working group that it didn't apply to people with disabilities and was usability.

Kathy: There wasn't consensus in the TF about this, and that we have notes that a holistic approach with existing SC would be best.

Josh: There will be more discussion about this.

SC for review by the group https://www.w3.org/2002/09/wbs/35422/SC_review_Jan2017/

<JF> I need to duck out now for a client call. Thanks all!

SC Proposal: accessible authentication #23

Josh: We have SC for review.

<Joshue108> accessible authentication #23

<Joshue108> https://github.com/w3c/wcag21/issues/23

<Joshue108> https://github.com/w3c/wcag21/issues/91

Josh: Accessible Authentication comments.

JamesN: Is this trying to eliminate passwords? There isn't a widely accepted alternative today, so that this would be making the Internet non-compliant.
... my reading is that it requires no passwords.

JohnR: That isn't our intent and we will look at it to make it clear.

AWK: What it seems to be saying is that either: your authentication meets this, or if you don't, then you need to have an alternative. I don't see what isn't something that requires memoriazation, even if it is only that you wrote down the password on a piece of paper. I don't see how we can measure this.

<Joshue108> https://github.com/w3c/wcag21/pull/91

Josh: the comments and feedback are rich. There is a pull request available. I invite people to comment on the pull request.

Wayne: Explain what you would want to see. What kind of interface would it be?

JohnR: Biometric information.
... a ring someone wears, or camera to recognize face.

Josh: Is that then requiring Biometric?

JohnR: No, it is requiring that an alternative be offered.

JamesN: but then you are prohibiting passwords.

<Lisa_Seeman> passwords can be an option but not the only one

<Lisa_Seeman> there shoudl be an alternitive that people can use who can not use passwords

JamesN: as well as a password, you would have to have some other way of authenticating into a system

James: The others are supplemental to password. Even on iOS, you have to authenticate with a password.

<Lisa_Seeman> note there is a w3c speck on secure authetification that supports mulitple methods with handshaking

<Lisa_Seeman> using that spec supports conformance

<Glenda> I think the intent has to do with authentication that asks math questions

<Zakim> Greg, you wanted to ask whether a site being compatible with UA password caching would count as complying

James: 3rd party authentication is prohibited in some industries because people can lose control it.

<Greg> If a site is coded to be compatible with UA password caching, it offloads the memorization burden from the user.

GregL: If people use @@@, then that would comply.

<Lisa_Seeman> note without this many many people can not use the website

<Joshue108> +1 Shawn

Shawn: Since this is not dependent on the authors themselves, I don't see how it would apply to authoors. We need to get someone to help with security expertise.

+1 shawn

<jamesn> +1

<shwetank> with regards to alternatives to passwords, we should also keep in mind potential privacy issues, so big +1 to involving people proficient in the security domain to review that SC

<Greg> To answer the point raised by Shawn, a site can be coded to be incompatible (or less compatible) with password caching. A simple example is where the username and the password are entered on separate pages, or where custom input controls are used.

<Lisa_Seeman> note that the w3c security standard support compliance

Josh: We will come back and review this

Wayne: If we can get the security issue to a reasonable amount, we should publish it so we can get feedback from the wider security community.

<Lisa_Seeman> we did discuss it at TPAc with the security WG, this is completely compatable. authers just have to use the standard

RESOLUTION: Issue 23 Accessible Authentication is not approved at this time and needs further work. The SC manager will reiterate

<Lisa_Seeman> Completely disagree

SC Proposal: Manageable blocks #24

<Lisa_Seeman> please renter this when I can explain

<Joshue108> https://github.com/w3c/wcag21/issues/24

Josh: 4 Yes, and 5 Nos

<Lisa_Seeman> it was in the text

<Lisa_Seeman> of the SC

<Lisa_Seeman> benifits and techneques

<Lisa_Seeman> people should have to read the whole thing before voting against including people into accessibility

<Lisa_Seeman> if anything I said was new then people voted to exclude people without bothering to read the whole SC

<Wilco> +1 on reproduce argument

JamesN: SOmeone would have to read all the text to determine if it has only one idea. There is no automated way to do that. The first exemption could be apply to everything. The last exemption would require user testing. That will be impossible to reproduce. People could disagree whether it passed.

<Joshue108> I like the sound of breaking up vids to shorter chunks also.

JamesN: I like the media side, breaking media into smaller units is a good idea, but 6 minutes may be too arbitrary

<alastairc> Lisa_Seeman where was the security spec? I didn't see that in the github description, could you add that as a comment please?

<Lisa_Seeman> look at the links

<Lisa_Seeman> they show the reserch behind the 6 minuetes

<Lisa_Seeman> well based

JohnR: James, how can we make it better?

JamesN: I haven't looked at everything, and haven't had time to be able to come up with ways of solving it.

Josh: These have been out for a while, and they are open to make more comments.

<Joshue108> Would like the group to note that they can come back to these SCs over the coming weeks.

David: As someone who evaluates websites, I don't see how I could test it. I could pick representative pages and extrapoloate, which we do in some areas. It's a big requirement that is hard to test.

<Joshue108> We dont expect people to have perfect solutions instantly - the suggested SCs need time to percolate.

<Lisa_Seeman> As somone who test website I disagree

<Glenda> David, it made me think that if I had to test this…I would need a tool like the Hemingway App http://www.hemingwayapp.com (not to say this is a solution we would all agree on…but it was a possibility of how I could approach testing). Then I felt like I was playing English teacher.

David: It is somewhat arbitrary and its a burden on corporations that are spending thousands on remediation. I am open to change.

Wayne: What is the scope on this kind of information? It seems like a narrower scope of types of paragraphs. Would this be limited to instructions?

<shwetank> +1 to David's point of people testing internationally not being super fluent in the language of the site being tested. Happy for comments who could change my view.

<Lisa_Seeman> scope is Important information. this has been defined

<Joshue108> I could see this working well as a recommendation or best practice but as a success criteria.

Wayne if it is something new written on the web, the writer may not have figured out the main point yet, but if it is instruction, then it makes sense for it to be restricted to one item. I think the scope need to be tightened.

Josh: You are welcome to re-iterate and bring it back to the group. There are substantial points being made.

<Glenda> John, we moved to “essential” information instead of “important”. You might want to think about that http://www.w3.org/TR/WCAG20/#essentialdef

JohnR: I think Accessible Authentication has a better chance, and I will work on that, and then work on Manageable Blocks.

<JohnRochford> * Thank you, Glenda.

RESOLUTION: Issue #24 Manageable Blocks was not accepted by the group and may have another iteration

SC Proposal: Resize Content #77

<Joshue108> https://github.com/w3c/wcag21/issues/77

Josh: Resize content is issue 77. 7 people who accepted, and a few with recommended changes

<alastairc> BTW: Several comments on 77 were for the old text, please see https://github.com/w3c/wcag21/issues/77#issuecomment-274900369

<alastairc> That's for JamesN, AWK, Greg

Glenda: I support it and just want clarity that it applies to all content.

JamesN: I am concerned about applications that are emulating native, it seems to require responsive design and not every application should use responsive. I'm thinking about IDE on the web, but toolbars could result in massive vertical scrolling

Wayne: This is taken in context with the ability to reflow. When you start making extensive changes to the size and layout. This is a tool for people who want to look at a page and use it, but not to the extent of doing deep work on it. It's a compromise betweewn the two.
... We don't care if you have to horizontal scroll to get to a block, only about horizontal scroll to read the block.

<alastairc> JamesN: Does the exception not work for that? Displaying code that doesn't reflow seems like essential to it's use.

Wayne: We dont' want people to hscroll to read a paragraph.

<Wilco> +1 to rewording, this isn't all too clear from the text

<alastairc> "Content can be resized to 400% without loss of content, functionality or requiring two-dimensional scrolling, except for parts of the content where fixed spatial layout is essential to use or meaning."

<Glenda> +1 to Wayne’s focus on horizontal scrolling on each line. (horizontal scrolling for a block is okay)

JamesN: You need to reword to address that, and it is not clear in the SC as is.

<shwetank> +1 to rewording from my side too.

Wayne: We will work on this

JohnR: The manageable block is 5 to 4. What is the criteria that we reject it?

<KimD> *I voted late, it's 4 accepts and 6 do not accept

<Glenda> For Issue 24, at least 2 of the “accepted” are on the condition that it move to AAA

Josh: There were substantial objections. The criteria for acceptance is that the group thinks it is on the right track.
... what are the nuances at any particular time? We have to make a call on it.
... there may be objections, but you may get a good idea and know how you want to address it.

David: Blocks of text instead of text as a suggestion for Wayne on 77

RESOLUTION: Issue 77 Resize Content is accepted with minor changes

<jamesn> there is an accept with changes in #9

<David_MacDonald> https://github.com/w3c/wcag21/issues/58

(discussion of the survey structure and what links to the survey. )

Look for more information in the survey, the links may not always be obvious.

<Glenda> Congrats on the Charter! Well done, y’all!

RESOLUTION: Issue #9 Informational Graphic content is accepted by working group

Issue 58 will stay open to be addressed next week.

<laura> bye.

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

31 Jan 2017

Attendees

Contents