W3C

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

23 Sep 2014

See also: IRC log

Attendees

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
Chair
AWK
Scribe
Mike_Elledge

Contents


<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

TPAC registration reminder

<AWK> TPAC meeting page: http://www.w3.org/WAI/GL/2014/10/tpac-2014

<AWK> TPAC meeting Sunday 1pm @ Google

TPAC registration reminder. If you have not registered, please do so asap per Michael. The plan is for 1PM Sunday meeting at 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.

Survey for September 23, 2014 https://www.w3.org/2002/09/wbs/35422/20140923/results

Survey for Sept 23.

AK: First item is largest.

forms tutorial review.

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.

Follow up on Aside technique https://www.w3.org/WAI/GL/wiki/Using_the_aside_element_to_indicate_tangentially_related_content

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

Mobile update to G4

Survey for September 23, 2014 https://www.w3.org/2002/09/wbs/35422/20140923/results

Mobile Update to G4

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.

Clarify the diffrence between F40 and F41

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

Placeholder Accessibility

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

Summary of Action Items

[NEW] ACTION: Josh to send collective feedback to Shadi [recorded in http://www.w3.org/2014/09/23-wai-wcag-minutes.html#action01]
[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014/09/23 16:31:51 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]