- From: Jeanne Spellman <jspellman@spellmanconsulting.com>
- Date: Tue, 31 Jan 2017 12:41:21 -0500
- To: WCAG WG <w3c-wai-gl@w3.org>
- Message-ID: <f1e44e40-512c-ad8c-0629-001dc370bc8d@spellmanconsulting.com>
Formatted minutes:
https://www.w3.org/2017/01/31-wai-wcag-minutes.html
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]W3C
[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
Attendees
Present
AWK, KimD, Joshue108, Rachael, JohnRochford, Kathy, JF,
kirkwood, Lauriat, Laura, Greg_Lowney, David_MacDonald,
Jeanne, Rick_Johnson, Katie_Haritos-Shea, shwetank,
adam_solomon, steverep
Regrets
Jim_Smith, Makoto, Mike_Pluke, Lisa_Seeman, Marc_Johlic,
Mike_Gower, Moe_Kraft, Mike_Elledge, Bruce_Bailey,
Alastair_Campbell
Chair
Joshue
Scribe
jeanne
Contents
* [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
https://www.w3.org/2002/09/wbs/35422/SC_review_Jan2017
/
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
[13] https://www.w3.org/WAI/GL/wiki/Scribe_List
<AWK_> Scribe list:
[14]https://www.w3.org/WAI/GL/wiki/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!
[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>
[15]https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Ability_t
o_Override
[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
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
[16]https://github.com/w3c/wcag21/issues/2
[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
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>
[18]https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1#Version_3
_Changes_.28Jan_29.2C_2017.29_Incorporating_Comments_Round_2
[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/ad8b5f43f707a
a58d9257197d33a4b48b035dd0e
[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
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
[21]https://www.w3.org/2002/09/wbs/35422/SC_review_Jan2017/
[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
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> [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
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> [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
teacher.
[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
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
[27]http://www.w3.org/TR/WCAG20/#essentialdef
[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-274900
369
[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
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> [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
reiterate
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