Minutes of AGWG teleconference of 31 January 2017

Formatted minutes:

Summary of Resolutions:
Issue 23 Accessible Authentication is not approved at this time and 
needs further work. The SC manager will reiterate
Issue #24 Manageable Blocks was not accepted by the group and may have 
another iteration
Issue 77 Resize Content is accepted with minor changes
Issue #9 Informational Graphic content is accepted by working group

Text of Minutes:


       [1] http://www.w3.org/

                                - DRAFT -

    Web Content Accessibility Guidelines Working Group Teleconference

31 Jan 2017

    See also: [2]IRC log

       [2] http://www.w3.org/2017/01/31-wai-wcag-irc


           AWK, KimD, Joshue108, Rachael, JohnRochford, Kathy, JF,
           kirkwood, Lauriat, Laura, Greg_Lowney, David_MacDonald,
           Jeanne, Rick_Johnson, Katie_Haritos-Shea, shwetank,
           adam_solomon, steverep

           Jim_Smith, Makoto, Mike_Pluke, Lisa_Seeman, Marc_Johlic,
           Mike_Gower, Moe_Kraft, Mike_Elledge, Bruce_Bailey,




      * [3]Topics
          1. [4]Welcome to AGWG
          2. [5]SC review process discussion
          3. [6]Update from SC managers
          4. [7]SC for review by the group
          5. [8]SC Proposal: accessible authentication #23
          6. [9]SC Proposal: Manageable blocks #24
          7. [10]SC Proposal: Resize Content #77
      * [11]Summary of Action Items
      * [12]Summary of Resolutions

    <KimD> +KimD

    <AWK> Scribes needed:

      [13] https://www.w3.org/WAI/GL/wiki/Scribe_List

    <AWK_> Scribe list:

      [14] 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!


    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

    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

    <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

    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.


      [15] 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

    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

      [16] 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> [17]https://github.com/w3c/wcag21/issues/59

      [17] 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

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

    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
    ... 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.


      [18] 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> [19]https://github.com/w3c/wcag21/issues/10

      [19] 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:

      [20] 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

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

    Josh: There will be more discussion about this.

SC for review by the group

      [21] 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> [22]https://github.com/w3c/wcag21/issues/23

      [22] https://github.com/w3c/wcag21/issues/23

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

      [23] 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

    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> [24]https://github.com/w3c/wcag21/pull/91

      [24] 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

    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

    <Lisa_Seeman> note that the w3c security standard support

    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

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

    <Lisa_Seeman> Completely disagree

SC Proposal: Manageable blocks #24

    <Lisa_Seeman> please renter this when I can explain

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

      [25] 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
    [26]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

      [26] http://www.hemingwayapp.com/

    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

    <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

      [27] 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> [28]https://github.com/w3c/wcag21/issues/77

      [28] 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

      [29] 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

    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

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

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

      [30] 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.

Summary of Action Items

Summary of Resolutions

     1. [31]Issue 23 Accessible Authentication is not approved at
        this time and needs further work. The SC manager will
     2. [32]Issue #24 Manageable Blocks was not accepted by the
        group and may have another iteration
     3. [33]Issue 77 Resize Content is accepted with minor changes
     4. [34]Issue #9 Informational Graphic content is accepted by
        working group

    [End of minutes]


Received on Tuesday, 31 January 2017 17:42:32 UTC