W3C

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

24 Sep 2013

Agenda

See also: IRC log

Attendees

Present
+1.978.443.aaaa, Kathy, +1.650.506.aabb, Peter_Korn, AWK, David_MacDonald, +1.703.861.aacc, Katie, Joshue, +1.703.225.aadd, Sailesh, Michael_Cooper, Loretta, Marc_Johlic, James_Nurthen
Regrets
Kerstin
Chair
AWK
Scribe
Kathy

Contents


<trackbot> Date: 24 September 2013

<korn> Good morning / afternoon. I'll be on the call in a moment...

<Joshue108> ScribeNick: Joshue

<Joshue108> https://www.w3.org/2002/09/wbs/35422/WCAGTechs20130910/

<Joshue108> https://www.w3.org/2002/09/wbs/35422/20130922comments/

<AWK> https://www.w3.org/2002/09/wbs/35422/WCAGTechs20130910/

WCAG review of Techniques Task Force: ARIA techniques for 10 September 2013 (We need to do #4, #5, #8 only)

<Loretta> zaki, IPCaller is Loretta

<Joshue108> AWK: Lets look at the first survey.

<Joshue108> AWK: Lets look at number 4 using aria landmarks to identify regions of a page.

<Joshue108> AWK: Loretta, I'm not sure how many of these have been looked at.

<Joshue108> DMacD: I've taken care of most of these, so I'm happy to discuss.

<Joshue108> AWK: Ok, lets start then.

<Joshue108> DMacD: First comment from Kathleen, and I agree about using only one main region, but the spec actually doesn't require that.

<Joshue108> DMacD: There are cases, for portals etc and may be valid use cases, would like others opinions.

<Joshue108> SP: Yes, I agree with your comment and raised it with you, and saw this covered in spec, so I agree with your change to the technique.

<Joshue108> AWK: Kathy, as commenter - what do you think?

<Joshue108> KW:I'm fine with that, for the most part there should only be one but I guess there are situations where it may happen.

<Joshue108> KW: I'd like the suggestion that there should only be one tho.

<Joshue108> <some word smithery discussion>

<Joshue108> PK: I'm curious, is it possible to enumerate the situation that point directly to where you can have more than one, portals etc. Other samples would be useful.

<Joshue108> PK: There could be iframes and times when you have a sigle URI eg.

<Joshue108> DMacD: That may limit use cases.

<Joshue108> PK: I'd worry about confusion amongst users where there are multiple names etc..

<Joshue108> PK: You could point to the section of the spec maybe?

<Joshue108> DMacD: Ok, I could do that.

<Joshue108> DMacD: Other thoughts?

<Joshue108> AWK: It sounds like its new enough, and support is still underdeveloped etc but it could be something we need to keep an eye on and maybe create failures that identify bad use cases.

<Joshue108> PK: I agree, that would be nice.

<Joshue108> DMacD: <further wordsmitthery and joviality>

<Joshue108> AWK: The first part of the change sounds good.

<Joshue108> DMacD: Sounds like a failure technique is a plan.

<Joshue108> AWK: Lets look at Michaels comment.

<Joshue108> DMacD: agrees with Michaels suggestion.

<Joshue108> AWK: Sounds good, Michael is saying kinda what we have with headings, that they reflect the reality of the page content.

<Joshue108> AWK: So the landmarks should reflect the page content.

<Joshue108> DMacD: People are looking for how to do landmarks properly, so I can modify the technique and cross reference appropriate techniques etc. Yes?

<Joshue108> AWK: Ok, do other people have the concern that the labelling is tangential? Or is it what you need to know to do landmarks effectively?

<Joshue108> KW: I think its critical.

<Joshue108> AWK: David, do you think this is easy to do?

<Joshue108> DMacD: Yup.

<Joshue108> KW: One of the things I recommend is to make sure all of the content in the page is actually in a landmark.

<Joshue108> KW: If there isn't content in a section that this functionality is being used, then they may miss it.

<Joshue108> DMacD: MarcJ had mentioned this in the past, Michael was opposed to this IIRC.

<Joshue108> MJ: Yes, we should include a note on this if we can - we do this inhouse in IBM.

<Joshue108> DMacD: Ok, I'll do that. Anything else?

<Joshue108> DMacD: We do mention SR users in the next paragraph, so don't agree with Joshs comment.

<Joshue108> +q

<Joshue108> JOC: I'm with the 'this is for SRs' school at the moment.

<Joshue108> KW: Screen Magnifiers support it, so I don't want to narrow the definition.

<Joshue108> AWK: So this is a little like headings, in that native browser support is poor but there are plug ins. This is reasonable and beneficial.

<Joshue108> AWK: David you were asking for Marcs thoughts?

<Joshue108> MJ: David Todd wrote the plug in!

<Joshue108> MJ: There are use cases for it being used by more than SRs. Does it hurt if we don't say this?

<Joshue108> DMacD: We say it in the next sentence anyway.

<David> Landmark roles (or "landmarks") break the page into easy to navigate sections. Landmarks help assistive technology (AT) users orient themselves to a page and help them navigate easily to various sections of a page.

<Joshue108> SP: Instead of SRs you can say its exposed to AT used by vision impaired users - Dragon doesn't get the landmarks etc. There is also a note about browser plugs but in the resources section there should be a link to one of those.

<Joshue108> DMacD: Ok, I have a link here.

<Joshue108> AWK: You do have a link to the browser plug?

<Joshue108> DMacD: Yup, we're good?

<Joshue108> AWK: Are others happy?

<Joshue108> KW: It only helps those that support landmarks.

<Joshue108> DMacD: Maybe we should say some.

<Joshue108> LGR: When i see that I think it reads that landmarks won't help them.

<Joshue108> KW: You should have other techniques at work.

<Joshue108> LGR: Thats a whole AT discussion!

<Joshue108> AWK: If we wanted to call it out..we could say refer to UA notes for current support.

<Joshue108> LGR: + 1

<Joshue108> DMacD: I'll do that.

<Joshue108> DMacD: <reads next issue>

<Joshue108> AWK: Lets skip to Lorettas comment.

<Joshue108> AWK: Thats already dealt with.

<Joshue108> DMacD: <reads tech> Region mapping in JAWS has been fixed IIRC.

<Joshue108> LGR: I'm reading the text and it talks about region NOT being a landmark.

<Joshue108> LGR: From our technique..<reads tech>

<Joshue108> DMacD: Ok.

<Joshue108> LGR: It's like we are throwing region in with the rest and it not sure why we doing that..

<Joshue108> DMacD: Delete sentence?

<Joshue108> LGR: One of our examples uses region..

<Joshue108> DMacD: Region is technically not a landmark?

<Joshue108> AWK: <reads ARIA spec>

<Joshue108> DMacD: Sounds like its not a landmark.

<Joshue108> AWK: Definitely not, I commented along these lines. We may need seperate sufficient techniques etc.

<Joshue108> AWK: I don't think this technique looses out by removing it.

<Joshue108> DMacD: Ok, I'll edit that.

<Joshue108> AWK: So you're going to take out example 5?

<Joshue108> LGR: Also look at 4.

<Joshue108> MJ: Before we remove it, under the roles model - it is saying that if none of the other landmarks fit you can use it an mark it up.

<marcjohlic> "When defining regions of a web page, authors are advised to consider using standard document landmark roles. If the definitions of these regions are inadequate, authors can use the region role and provide the appropriate accessible name."

<Joshue108> LGR: This is where we wrote it up and could list it as related techniques.

<Joshue108> <discussion on UA support and user experience>

<Joshue108> JN: If content isn't replaced, its a UA bug.

<Joshue108> JN: aria-labelledby, aria-label then native semantics, then child content if role defined as such, then title and CSS subs.

<Joshue108> DMacD: Would that change stuff for us?

<marcjohlic> q

<Joshue108> DMacD: I've refreshed it is the example ok now for everyone?

<Joshue108> yup.

<Joshue108> DMacD: The test procedure needs to reflect the change?

<Joshue108> AWK: Yes, we should modify the test procedure.

<Joshue108> DMacD: Suggestion?

<Joshue108> <discussion on test procedure verbiage>

<Joshue108> AWK: If example 3, was in a page that didn't have primary, secodary etc - would be regard that as sufficient?

<Joshue108> JN: Can't see why not.

<Joshue108> AWK: Ok.

<Joshue108> JN: Not as wrong but not as good etc.

<Joshue108> DMacD: I've added some text, let me know if ok?

<Joshue108> <no objection>

<Joshue108> AWK: Ok, thats that.

<Joshue108> AWK: There was another comment about using Skip - instead of navigate from Kerstin.

<Joshue108> DMacD: At some stage there may be sufficient support for that.

<Joshue108> AWK: Ok, I don't feel too strong about it either way.

<Joshue108> DMacD: I can change that to navigate, will have something to show in ~ 10 mins.

<Joshue108> AWK: I suggest if comments are address that we accept it as amendened pending DMacDs changes.

<Joshue108> AWK: Any objection?

<Joshue108> JN: What was conclusion on region?

<Joshue108> AWK: We are doing a seperate technique for that.

<Joshue108> JN: Perfect.

<Joshue108> AWK: Hearing no objection - done.

<Joshue108> <discussion on latest batch of ARIA techs>

<Joshue108> AWK: James do you want an action.

<Joshue108> JN: Give me a sample technique title

<Joshue108> <various suggestions>

<jamesn> http://www.w3.org/WAI/GL/wiki/index.php?title=Using_the_region_role_to_identify_a_region_of_the_page&action=edit&redlink=1

<Joshue108> AWK: Ok, next techniques- re invisible labels.

<Joshue108> AWK: TF people, have you a sense of how many comments have been addressed?

<Joshue108> LGR: I don't know who owns this!

<Joshue108> LGR: Do we agree on the disposition of the comments?

<Joshue108> AWK: Lets have a look.

<Joshue108> AWK: Most agreed, except one ref to linked docs in the works.

<Joshue108> http://www.w3.org/WAI/GL/wiki/Using_ARIA_landmarks_to_identify_regions_of_a_page

<Joshue108> http://www.w3.org/WAI/GL/wiki/Using_aria-label_to_provide_an_invisible_label_where_a_visible_label_cannot_be_used

<Joshue108> AWK: We're on number 5.

<Joshue108> AWK: Do people not like the other examples. James, you don't like contenteditable?

<Joshue108> JN: Its tricky.

<Joshue108> +q

<Joshue108> JOC: I've found support on desktop for contenteditable and aria-label to be good.

<Joshue108> JN: Yes, not so hot on mobile.

<Joshue108> JN: We should put ' on mobile operating systems'.

<Joshue108> AWK: Then example 2, do we have concerns?

<Joshue108> JN: For me this is a little weird.

<Joshue108> SP: Yes, regarding these buttons - we need to be clear what kind of buttons they are - if an image then alt may be best - if a button with a value, say its name then aria-label may be better.

<Joshue108> SP: So if input type = button and you need more than the generic value for AT users then the label may work ok.

<Joshue108> AWK: In example 2 right?

<Joshue108> SP: Yes.

<Joshue108> <further discussion>

<Joshue108> SP: It could be button text, then yes - the aria-label may work. The other instance is examping on the value attribute.

<Joshue108> JN: Which is what this is.

<Joshue108> SP: So regarding the visual content, then the plus sign is rendered by the AT.

<Joshue108> <further discussion on role - button etc>

<Joshue108> KW: I don't use aria-label on a button - the title att works better.

<Joshue108> JN: Notes spec definition.

<Joshue108> KW: We have role button there.

<Joshue108> AWK: I don't like putting role= button just to make up for AT limitations.

<Joshue108> AWK: If we do leave it, we need a note to say these controls have role=button added to make up for lack of support in AT.

<Joshue108> JN: We don't have that in example 1, which is similar.

<Joshue108> AWK: So Kathy and others, do we need this example with others to make it good enough.

<Joshue108> KW: Don't think so.

<Joshue108> AWK: Discusses Bruces comments, may have been addressed.

<Kathy> scribe: Kathy

<Joshue108> ScribeNick: Kathy

AWK: Michael asks whether CSS is required

James: Not necessary

<Joshue108> agree to removing, simplifying the CSS.

AWK: as long as we have the live examples, it is fine

James: Remove the extra stuff in example 1

AWK: does that make example 1 and example 2 the same

Sailesh: The examples are the same

James: Should we remove #2

AWK: any objections?

<Joshue108> Yes

James: I will remove example 2 and edit example 1

David: Have code examples is good

AWK: live examples are available with the code

Michael: The two paragraphs are not swapped but it is ok

AWK: it would make sense to switch them

Sailesh: Support for the title, sometimes the label and title will be spoken. The aria-label is the only thing that gets announced. Title will provide tooltip so that may be a better candidate in some cases

AWK: That gets into more nuanced discussion. This is something that you may need to do in some instances. This is sufficient. Worry about over complicating with the if then scenario

Sailesh: You would need to explain the scenarios about non-sighted and sighted users

David: two things. We need to add to the description about the aria-label overriding the label on the form field. It is a common error.

AWK: we had some text that we can pop in here

David: The first example, the window cannot be closed with ESC key. Suggest that we add this to the example

James: not required by WCAG

David: right, but it is a best practice
... suggesting adding it to just the live example. People grab the code and expect it to be right

James: We would need to write a library of JavaScript code

AWK: nor can we provide maintenance on these

James: If we can use JQuery UI but we would need to test

David: I will back off on this point

James: Getting back to title, if needed for a sighted example, that would be a different success criteria. Also not correct according to the ARIA specs

Sailesh: There is a success criteria for title

James: That one does not use aria-label. Here we are just talking for this example

Sailesh: Different types of buttons have different types of attributes. If you have a button with no text and a sighted user need to mouse over it to find out what it is

James: That will not pass with other success criteria

Sailesh: Sometimes you need to use link anchor with role="button". There are many different ways

James: there are other techniques to cover this

Sailesh: Here we should have a cautionary note that in some situations aria-label works best but in other cases title may be best

AWK: Where would that go?

Sailesh: Description

Loretta: ironic that we are recommending the title attribute since there is issues for keyboard users

AWK: Not sure about title attribute. Maybe a note that aria-label is not the solution for every situation

Loretta: That is true of most techniques and ARIA

Sailesh: For most techniques, the situation is listed. That is what I am recommending here

AWK: Do you think the first paragraph indicate that?

Sailesh: yes

AWK: does that address all the comments, Sailesh?

Sailesh: Yes

AWK: Not fond of example 3
... maybe we should add telephone example

David: That is a good idea. I see that a lot

James: Does anyone have one

AWK: Let's add that
... Add a placeholder and if someone has one we can insert it
... success criterion 3.3.2 related

James: 4.1.2

AWK: 1.3.1 because it is information conveyed through presentation. The X is clear visually but not if it is read as X.

Loretta: 1.1.1

AWK: The X is text

Loretta: gets nervous about putting it under 1.3.1

<Zakim> Loretta, you wanted to say should this technique also apply to 4.1.2?

AWK: fine with putting it under 4.1.2

Sailesh: another example is to have multiple buttons that are the same, but for non-sighted users you may want to make this descriptive with aria-label
... You could also use aria-labelledby

David: I would use aria-describedby

Sailesh: This to expose the name on the button so it should not be aria-describedby

<jamesn> better would be aria-labelledby="add4 lap4"

http://mars.dequecloud.com/demo/form-markup.htm#lap4

<jamesn> http://www.w3.org/WAI/GL/wiki/Using_aria-labelledby_to_concatenate_a_label_from_several_text_nodes

AWK: we have an example that is similar
... we will leave this one open

James: if someone has a telephone example

AWK: we need to figure out how to accelerate through these

James: can we use SSN instead

Kathy: yes

AWK: if you did not respond to the second survey, please do
... will send a note to see if your comments have been addressed later this week

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013/09/24 16:35:42 $

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/we can/nor can we/
Found ScribeNick: Joshue
Found Scribe: Kathy
WARNING: No scribe lines found matching ScribeNick pattern: <Joshue> ...
Found ScribeNick: Kathy
ScribeNicks: Joshue, Kathy
Default Present: +1.978.443.aaaa, Kathy, +1.650.506.aabb, Peter_Korn, AWK, David_MacDonald, +1.703.861.aacc, Katie, Joshue, +1.703.225.aadd, Sailesh, Michael_Cooper, Loretta, Marc_Johlic, James_Nurthen
Present: +1.978.443.aaaa Kathy +1.650.506.aabb Peter_Korn AWK David_MacDonald +1.703.861.aacc Katie Joshue +1.703.225.aadd Sailesh Michael_Cooper Loretta Marc_Johlic James_Nurthen

WARNING: Replacing previous Regrets list. (Old list: Cherie)
Use 'Regrets+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Regrets+ Alan


WARNING: Replacing previous Regrets list. (Old list: Alan)
Use 'Regrets+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Regrets+ Kerstin

Regrets: Kerstin
Agenda: http://lists.w3.org/Archives/Public/w3c-wai-gl/2013JulSep/0140.html
Found Date: 24 Sep 2013
Guessing minutes URL: http://www.w3.org/2013/09/24-wai-wcag-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]