See also: IRC log
<trackbot> Date: 23 September 2014
<Joshue> Scribenick: Mike Elledge
<Mike_Elledge> scribe: Mike_Elledge
AK: Dana, officially a meeting
group of the members, but you are invited to listen in to the
call. We can talk after about becoming a member.
... You may run screaming from the room...
... Dana is from State of OK Rehab Services, IT side
<AWK> TPAC meeting page: http://www.w3.org/WAI/GL/2014/10/tpac-2014
<AWK> TPAC meeting Sunday 1pm @ Google
<AWK> Monday @ official TPAC site
AK: Also Monday at the TPAC site.
MC: This is a terrible head set. Teh meeting hotel is selling out. Book soon. Looking at overflow hotels, but don't know availability. Make rez right away!
<Joshue> http://www.w3.org/2014/11/TPAC/#venue
<marcjohlic> http://www.w3.org/WAI/GL/2014/10/tpac-2014
MJ: There is a link on the meeting emai. What's on for Tuesday? Techniques?:
AK: As of now, not great response
for that. No decision yet. Wld be informal. Finding a location
where there's coffee and wifi. A few people spending time
working and talking.
... Don't have numbers to say it's official. If enough people
around, we can. Otherwise listen in on Advisory Bd meeting.
MJ: No official registration for WCAG WG.
MC: If we feel strongly we will. Loretta to inform.
L: Would be nice for badges. But will have space.
AK: Space at Google?
L: Sure.
AK: Will get L a full list of names. Two weeks in advance.
L: Fine.
... On our own for lunch food. Maybe can get dinner
afterwards.
MC: Just need list of names then.
AK: First item is largest.
AK: Had lots of issues.
... 1 okay. 2 minor. 2 major.
MC: Shadi wants us to consolidate our answers. DK exactly what that means. Forward our comments?
<David> +
MC: Shadi wants just the
feedback. Do we want to find consensus or no major objections
to comments. Skimming thru A's comments. No objections so far.
But different perspectives.
... Different ways to accomplish. Looks like some preferences.
But no objection to sending as is.
<jon_avila> I generally agreed with Andrew's comments.
D: Agree with A. This is very important. W3C tutorial is our consensus. Our techs don't even have this level of detail. Have to make sure it's right. Not ready for primetime.
J: Generally agrees with A's comments.
AK: One of concerns: ARIA is
something we are advocating for use, but tutorial seems to be
against. Title attribute vs. new techniques.
... If target is new developer should be talking to them about
right way to do it, as well as their preparation.
... Providing advice circa 8 years ago. Others concerned?
D: Totally with you.
JC: Some of ARIA examples not right either. Agree with you. Also some nice things, validation, JS, right direction. but needs tweaks.
AK: Described by?
JC: Describedby referring to unicode symbol. Checkbox. Used to show validation cycle is correct. But screen reader won't pick up on it. Didn't work with VO. Didn't test w/ JAWS or NVDDA.
JS: Didn't work with my testing.
JC: Will dig it out.
<Joshue> http://www.w3.org/WAI/tutorials/forms/notifications/
AK: Anything else? Josh: labeling controls. Michael?
<Joshue> Its in example 1
MC: No. Don't think so. Minor suggestions.
JC: Static inline messsage.
AK: That is interesting.
JC: Wld be cool if it worked.
AK: Largest concern is top of
labeling controls provide labels using label attribute, rare
cases title attribute. Worry about oversimplification.
... Don't want to review website with button with ID element
when most cases is just button content and that's
sufficient.
... Risk of confusing people in oversimplifying things.
Questions or concerns about conveying that.
<Joshue> ME: Looking at this maybe its a matter of indicating of when it is a good idea to provide additional levels of explanation.
<Joshue> ME: Showing when it is appropriate.
<AWK> Mike: Haven't looked at it much recently.Maybe we need to indicate when it is a good idea to provide the additional level of information via for/id?
AK: Part of what I question.
Maybe start out with table that indicates standard control
types. So ppl don't think they typically need id for label or
labelledby.
... Any objections to sending on to Shadi and Eric?
... Will do that then (no objections).
<David> http://davidmacd.com/test/describedby-check.html Works in NVDA and JAWS... but as per joshe not in VO
JO: Made some good points. Overall feeling of the tutorial. Some examples seemed things did several years ago. Not best practice anymore.
AK: Nothing more, my main issues.
RESOLUTION: Chair to send on responses to Shadi.
<Joshue> ACTION: Josh to send collective feedback to Shadi [recorded in http://www.w3.org/2014/09/23-wai-wcag-minutes.html#action01]
<trackbot> Created ACTION-273 - Send collective feedback to shadi [on Joshue O Connor - due 2014-09-30].
AK: David had a question.
D: Implies should not do keyboard accessibility
?: Did that work with NVDA and JAWS
D: Yes. Both said check. Still wouldn't recommend if only 2 of 3.
AK: Not as concerned about "or". User can pause through multiple mechanisms...May not be a touch screen or voice command option.
D: How about "some examples of these are...." so don't need "or" statements.
<David> Users who need more time to read it can pause or restart the scrolling through multiple predefined mechanisms (Examples are the Escape key on a keyboard, giving a voice command, and performing a gesture on a touch screen.)
K: I completely agree. The
long-term place where we want to be should not exclude other
current ways.
... Have to make it clear that whatever has been our key hook
still has to be part of our statement.
<David> add next sentence after that Note: Keyboard accessibility is always required under 2.1.1
AK: Are you suggesting a
change?
... I don't have any problem with D's text (above).
D: Some pressure from one mfr to move away from keyboard a11y--not there yet.
K: Confused. This is introduced
from mobile folks, where keyboard not only mechanism.
... Like redundant keyboard handlers for mouse. A hassle, but
still need both event handler for keyboard and touch.
Eventually, hope it will go away. But for new need it.
L: But we're claiming that it would be needed.
K: Would need to be consistent.
AK: G4, 2.2.1 Keyboard
accessible.
... These are the things you need to address success
criteria.
K: But don't want to remove key
handler element.
... Don't want to take people don't road where it won't work in
multiple devices.
D: Wouldn't want to confuse people.
K: Put in note that keyboard access is still necessary.
D: Fine with that.
K: Agree
JA: This is a bigger issue than
this technique. Just saying KB access is enough, may not be
sufficient. In iOS tab doesn't go into input fields. But Apple
has created other text. Keyword is probably interface.
... Say interface or equivalent.
... Tried to take technique and put into mobile, so struggled
with language to make it . In a device independent method...If
we come up with a solution we can apply it many places.
D: Keyboard interface? Have to
talk more with Jon about it. As long as can use it with
keyboard can call it what you want.
... Maybe that was technique from couple of weeks ago. But if
can do with keyboard is what is important.
JO: I guess terms are like
snapshots in time. Have to be concerned about future-proofing.
Be careful to use terminology that looks forward as well as
backward.
... For example many types of keyboards.
K: Agree. Was just going to say
that. Like keyboard interface. Using on PC, using on their
phone screen, would work with any kind of interface adds
future-proofing. Has to be some keyword or component.
... So don't have to explain each time.
<Joshue> ACTION-273: Collected working group feedback on forms tutorial sent to Shadi on 23rd Sept
<trackbot> Notes added to ACTION-273 Send collective feedback to shadi.
K: Note that it's for all the techniques.
<Joshue> close action-273
<trackbot> Closed action-273.
Jon: We don't want to remove kb
a11y from an environment. But when testing may not have kb
available for that device.
... Radio button. May be built for keyboard, but not in iOS,
still want to make conformance claim.
James: Device independence may
not be correct term. May work on only one device that is
supported.
... Only has to work on device on platform that we're on.
AK: Similar to what Jon said
before.
... Have edit that would work for this item?
<AWK> Change first bullet to: Users who need more time to read it can pause or restart the scrolling through multiple predefined mechanisms (Examples are the Escape key on a keyboard, giving a voice command, and performing a gesture on a touch screen.)
<AWK> (the second sentence of the first bullet)
AK: Changing second sentence of first bullet. David adding?
D: Note saying that KB a11y is still necessary.
AK: Where would that go. KB interface change?
D: Guess it's okay.
AK: Where would you put it?
D: End of bullet. Clarify the
bullet.
... We use keyboard interface. So perfectly fine. Just a
reminder. At end of bullet.
<David> All functionality of the content is operable through a keyboard interface without
D: As per 2.2.1...
<David> As per 2.1.1 All functionality of the content needs to be operable through a keyboard interface without
<AWK> Add note to end of bullet #1: Note: Per success criteria 2.1.1, access via a keyboard interface is always required
D: Perfect!
AK: True enough to say. Do we need to say that in this technique for the other success criteria. Also other things we are talking about, not referencing all the other criteria.
D: If we have the bracket on first thing, won't fall on sword. Fine with wording.
K: Don't have to say 2.2.1. Say something about KB interface operability.
JA: Not sure we need to say anything about kb interface. This is about enabling content to be stopped. Then have to add to test. Wld be redundant.
L: Don't have to add to test. Just a reminder.
AK: Agree.
JA: Already talk about kb controls and shortcuts.
AK: Not getting too strong sense
that this has to be one way or other.
... Katie, any tweak we can add but keep text clean.
... My preference is to keep docs brief. If reference controls
and WCAG.
K: How about including kb interface support.
<AWK> This mechanism can be provided either through interactive controls that conform to WCAG or through keyboard shortcuts. If keyboard shortcuts are used, they are documented.
K: Can't see where it is right
now. But say complies with kb support.
... Now I see it.
AK: How about this. We accept the change in first bullet, then tell them accepted, but even looking at last sentence might need some tweak there.
K: When they clarify that put some reference to keyboard interface support.
AK: They're saying this is the clarification.
K: Katie will wordsmith.
AK: Accept modified technique as amended.
<jon_avila> https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/G4
JA: Does that include third
bullet as well?
... An addition.
AK: Includes adding the third bullet.
K: Last sentence was user's need bullet.
AK: Will go into wiki and will
change it.
... Any objections.
RESOLUTION: Accepted as amended.
<scribe> ACTION: Katie to review description for G4 to ensure that keyboard interface support is included. [recorded in http://www.w3.org/2014/09/23-wai-wcag-minutes.html#action02]
<trackbot> Created ACTION-274 - Review description for g4 to ensure that keyboard interface support is included. [on Katie Haritos-Shea - due 2014-09-30].
<AWK> ACTION: Katie to review description for G4 to decide if keyboard access mention is sufficiently helpful. [recorded in http://www.w3.org/2014/09/23-wai-wcag-minutes.html#action03]
<trackbot> Created ACTION-275 - Review description for g4 to decide if keyboard access mention is sufficiently helpful. [on Katie Haritos-Shea - due 2014-09-30].
<Joshue> close action-275
<trackbot> Closed action-275.
<Joshue> https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-WCAG20-TECHS-20140306/2955
AK: Jon had a comment. Refresh in 0 seconds unusable for everyone.
JA: Just removing 0 from refresh, and leaving it for redirects.
AK: My understanding as well.
MC: Finding it hard to review in this form.
<AWK> In github: https://github.com/w3c/wcag/pull/39
AK: Looked at changes in github
much easier.
... It does give you three tabs, files change where can see
what changes are indicated.
<Loretta> Can we include this type of link in the survey question for github submissions?
AK: Probably the easier way. In general, my conclusion is that comment is very helpful. Techniques were blurring the line. An easy fix.
RESOLUTION: Accepted as proposed.
AK: Revove aria5 and aria6.
... Should we clarify, Loretta?
L: Would be more helpful response
to commenter.
... Would put as part of second paragraph.
AK: See that now...
... When writing examples for techniques...
L: Live examples are more fully developed patterns, which you were concerned about.
JO: Like the comment text.
... People expect more from techniques...
L: Examples are longer.
<AWK> When writing examples in the techniques the working group focuses on code specific to the related success criteria, but in the live examples additional success criteria are also addressed, which address some of the issues you are concerned about.
AK: Not sure I worked in design
patterns...
... Does that carry the sentiment?
L: Sounds good to me.
James: Think L's text clearer and
plainer...will type in.
... After the second sentence.
That was Josh.
AK: Everyone happy with that?
+1
AK: Objections?
RESOLUTION: Accepted as amended.
<Joshue> I've updated the response
Dueling edits!
AK: L: Saying that authors meet UAAG 1.8?
L: Felt that response not very clear about what we were saying. Have a clearer answer, even if more complicated.
JO: Not sure where to draw the line. Whether authors meet WCAG. Put on author.
L: Right position.
... Saying they have the responsibility isn't saying what
they're responsibility is.
J0: Clarified in my text...
L: Need to say clearly, that if you know your environment, and browsers meet that responsibility, then you've done your due diligence. But if you don't know it's up to the author.
M: I'd like to see something more definitive. Maybe "in lieu of user agents giving placeholder text sufficient contrast by default, web authors have responsibility for ensuring it meets WCAG 2.0 guidelines."
<jamesn> Should we tell them how to do it to?
MC: Would put it as is it a11y supported. Then would reference WCAG.
AK: Last one. Just needed more of
an explanation of scripting.
... Any objection?
... Thanks all. Let us know if there are any comments so we can
put on survey. REGISTER FOR TPAC!!
<AWK> trackbot, end meeting
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/James: We don't/Jon: We don't/ Succeeded: s/James: Radio/Jon: Radio/ Found ScribeNick: Mike Elledge Found Scribe: Mike_Elledge Inferring ScribeNick: Mike_Elledge WARNING: No scribe lines found matching previous ScribeNick pattern: <Mike\ Elledge> ... ScribeNicks: Mike Elledge, Mike_Elledge Default Present: +1.405.951.aaaa, AWK, Joshue, David_MacDonald, Kenny, Loretta, Mike_Elledge, Marc_Johlic, jon_avila, Michael_Cooper, Dana, Cooper, adam_solomon, Katie_Haritos-Shea, James_Nurthen Present: +1.405.951.aaaa AWK Joshue David_MacDonald Kenny Loretta Mike_Elledge Marc_Johlic jon_avila Michael_Cooper Dana Cooper adam_solomon Katie_Haritos-Shea James_Nurthen Regrets: Alistair Sailesh Kathy Christophe Brent Found Date: 23 Sep 2014 Guessing minutes URL: http://www.w3.org/2014/09/23-wai-wcag-minutes.html People with action items: josh katie WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]