Web Content Accessibility Guidelines Working Group Teleconference

24 Mar 2015

See also: IRC log


AWK, Joshue, Kathy_Wahlbin, +1.650.464.aaaa, EricE, Marc_Johlic, Dan, Katie_Haritos-Shea, Mike_Elledge, jon_avila, Michael_Cooper, Loretta_Guarino_Reid, Kenny, James_Nurthen


<trackbot> Date: 24 March 2015

<Joshue108> is Joshue

<Joshue108> Joshue108 is Joshue

<scribe> scribe: marcjohlic

WCAG F2F @ TPAC Sapporo, and comment responses etc New survey https://www.w3.org/2002/09/wbs/35422/24thMarch2015/

<Loretta> zakim IPcaller is Loretta

Dan Frank - Wells Fargo - joining working group

DF: Creating an approach to scoring, prioritizing - metrics for accessibility testing

JC: Will send Dan a URI to work Shadi is doing also

<Joshue108> https://www.w3.org/2002/09/wbs/35422/24thMarch2015/%22

Would you attend a WCAG Face to Face meeting at TPAC Sapporo 2015?

JOC: 2 "definitely will be there" and 2 "definitely won't be there" responses so far

AWK: Need more responses from WG members before we can make a final decision

JOC: Would like to get a consensus as soon as possible

<Joshue108> [Updated Test Procedure F68] Procedure looks wrong

<Joshue108> https://github.com/w3c/wcag/issues/81

RESOLUTION: Leaving open awaiting more responses from members

<Joshue108> https://github.com/w3c/wcag/pull/85/files?diff=split

[Updated Test Procedure F68] Procedure looks wrong

KHS: Changes to my comment based on Andrew's response

<Ryladog> For all input, textarea and select elements in the Web page (EXCEPT those of type hidden, submit, reset, or button ) one of the following checks must be true:"

AWK: propose "inputs of type hidden.. etc" vs "those of type"

<Ryladog> For all input, textarea and select elements in the Web page (EXCEPT input type hidden, submit, reset, or button ) one of the following checks must be true:"

RESOLUTION: Accepted Katie's updated text for F68

<Joshue108> [Comment Response F3] Clarify the meaning of "is also available" in step #3 of F3 test #80

[Comment Response F3] Clarify the meaning of "is also available" in step #3 of F3 test #80

<Joshue108> https://github.com/w3c/wcag/issues/80

AWK: Agree there is an issue here - just want to ensure we are marking this against the correct SC
... If someone has CSS turned off, then an image may not appear then they may not have any alt text - is that was folks are talking about as well?

JOC: My understanding as well

JA: Also agree

AWK: Is that a Failure of 1.1.1 or 2.4.6 or a User Agent thing?

JA: I see it as a 1.1.1 because it's an image that doesn't have a text equivalent
... 2.4.6 Is that if you already have a heading or label then i has to describe the purpose

AWK: I was thinking it was a control image, but if it's just a content image then label doesn't really come into play

KHS: Even as a control image it will still fit under 1.1.1

JOC: Should we put a note in the technique?

LGR: Think we may be making this more complex than it is

<Mike_Elledge> !

AWK: Seems like we are depending on user agent behavior to fill the gap
... If we turn CSS off, we are counting on user agent to fill that gap

JA: The way I look at this is CSS is presentation only. We have a programmatic method but we also have to have a visual alternative...
... If this was a control, 4.1.2 would apply
... Some situations more SC could apply
... Until we have another technique, I would be careful about changing this one (this is the only one that covers need to present alternatives for CSS images)

JOC: Suggest leaving this open before making a response because it may hit a few areas that we didnt' consider

JA: We could make the same argument for color

LGR: But we have specific SC that address use of color
... This may be an oversight

KHS: Brings back the one that we wanted to get rid of in 508 around turning off CSS and having all functionality available (going away in Refresh)

RESOLUTION: Leave open while AWK works on wording

<Joshue108> [Comment response G136] Meaning of "Alternate version" is not clear

[Comment response G136] Meaning of "Alternate version" is not clear


JOC: Mixed response on this one

AWK: Commentor's comment was just on the example - don't think there is anything in G136 that says you "must do this" like link has to be called something specific
... We already have a standard that says you must name links appropriately

JOC: Issue is around ambiguity of "alternate version" - so we should clear that up

<Joshue108> On a Web site, for each page that does not conform to WCAG at the declared level, the first link on the page is called "Alternate accessible version" (or using other link text that properly conveys the purpose of the link). The target of this link is the alternate version of the page that conforms to WCAG at the declared level.


<Joshue108> +1

<Loretta> +1

<Joshue108> +1 from James

<Kathy> +1

<Kenny> +1

JN: Suggest dropping "alternate" and just got with "accessible version"

JOC: Agree


JOC: Preference for removing "alternate" but I can live with it

<Joshue108> MJ: I like as it will shorten link

AWK: Just updating the Example
... Test does not mention link text

JA: Does not say that it has to be first link either

JOC: Making me re-think the use of "alternate" - but that is a discussion for another day

RESOLUTION: Accepted as amended per AWK's suggested text minus the word "alternate"

<AWK> For each image added to the content via CSS, HTML style attributes, or dynamically in script as background images. 1. Check that the image conveys important information. 2. Check that a text equivalent for the image is not available programmatically. 3. Check that a text equivalent is not available visually when the CSS image is not displayed.

Returning to [Comment Response F3] Clarify the meaning of "is also available" in step #3 of F3 test #80

AWK: This doesn't change what we currently have, but it does make it clearer
... Would have to update Expected Results

<AWK> http://www.w3.org/TR/WCAG20-TECHS/F3.html

LGR: Is it possible to programmatically associate text for CSS images?
... Seems that the only method is for hiding the text when the image is present

JN: There are ways of doing this

LGR: Concerned that there are ways of approximating it - but not that specifically associate the text with the image

JN: They would both be associated w/ the same DOM node. Correct that the text is not associated directly w/ the CSS image, but it is INDIRECTLY associated via the DOM node
... People are going to be doing this anyway - so we need to provide them a way to do it correctly

LGR: What is is WCAG that makes it true that if an image is not available neither is the alt text.. Would it be 1.1.1? Discussion around that

JA: Strictly speaking you can't provide an alternative based on the text alt definition. You could still meet WCAG through other methods - so maybe not under 1.1.1 it could be under conformance
... If you had a chart that didn't provide all of the details via alt text, but the the details were provided on the page

AWK: The use case I see is where there is an icon - and for some reason they like to use <i> and maybe it has text inside it or sometimes it doesn't, and they use CSS to assign a background image
... The difference between this method and using <img> is that AT alerts the user that there is an image there
... It's very uncomfortable - probably an area where we should make a note for ourselves about future work. Feel that the INTENT is clear enough, but there might be enough wiggle room in 1.1.1 where an argument could be made that the <i> element is being made into non-text content
... Big question really is: We may be making some assumptions about what the UA is going to do with text alternatives

JOC: To James' point to what degree can we rely on the UA to handle that correctly (indirect association via the DOM)
... Do we need to leave open and work on the Test procedure more? My sense is yes
... I think we need to be more clear from the UA side on what is likely to happen in the majority of cases when CSS images aren't displayed. Things have change from when this was first written.
... Are there differences when CSS is off vs when CSS images are off

JN: We don't need to worry about CSS off for conformance

AWK: Let's leave this open for another week to look at this one

JA: If you're going to propose changing the Test procedures, also need to update the Expected Results

AWK: Agree

JOC: Agree and would help to clear up all of the "if" cases

ME: Wondering if we also need to take a look at SC for presenting alternate content

AWK: That's were we can put a note in the wiki, but we can't change the SC itself (normative)

RESOLUTION: Leave open (again)

Techniques work

Charter update

AWK: Brief update about charter - many of you have heard from us that the charters are out for review
... Word that we've gotten back is that we may need some modifications
... Substantial number of comments that came in on different topics
... Charter proposed did not have any normative work defined in it - and that was raised by a number of commentors
... So there are things going on, and if you're a member of a W3C company you can go in and review the comments.
... For WCAG the main comment was that WCAG is very important and that there needs to be Normative work going on. Folks have talked about normative extensions as opposed to "version" updates
... Based on conversations and WAI2020 meetings at CSUN, people feel there are pieces that might need to be updated. Want to validate what I was hearing with folks on the WG call

<jon_avila> YES!

<Kathy> yes!

<Joshue108> MJ: Yes

AWK: Do you feel that there is enough that we've identified via Mobile and Cognitive work that there are things that need normative work

KHS: Extensions are a good idea. We need to continue to leave the techniques as non-normative.
... So keep extensions normative - but any techniques that come out of those non-normative so that we can address any changes that are needed
... Would also include "Low Vision" concerns and possibly even "wearables" in addition to mobile

AWK: Extensions idea - similar to the way the ongoing work to HTML5 is being done
... Discussing that WCAG extensions could be handled the same way. WCAG would still be there - could be referenced, but that as extensions come out some other company / institution etc could say "OK we are WCAG plus Extension X"
... Then at some future time we could decide to wrap these all together
... That was the discussion at CSUN - smaller more agile extensions. And yes techniques would still be non-normative
... Even talking about finding ways to make techniques work even faster. For example what if Techniques were pulled off of the TR track and updated much more quickly
... We have already moved to every 6 months, but perhaps could make it faster. Techniques could be modified, rolled out more readily. Just something that was discussed.
... We will be updating everyone about what happens, but we know it's certainly going to be a topic for a bit

Techniques work

JOC: Talking about work we need to do as a WG - techniques in Mobile space

KW: We're taking information we have in the Mobile note and looking at the 4 key areas we discussed in the F2F
... What are best practices that we need for keyboard navigation - what are things we need to document as Best Practice
... What we could use help on is getting that list together - then going back to write the techniques
... One thing we are waiting for is to see which way things go on WCAG Extensions as that could affect how we go about writing techniques
... Please review Note and provide feedback


KW: Starting a new wiki page and inserting some placeholders in the Note. Kim is creating new wiki this week to track things that came out of F2F (touch size for example and research around all of that)
... Collecting a lot of information around a lot of things - want to check research that is out there to help define as best practice vs advisory etc

AWK: A lot work to be done - part of what Josh and I are suggesting is that it would be great for people looking over work that needs to be done, and seeing where they could contribute - their areas of expertise
... Another example is that in the WCAG technique Examples use HTML 4 - where they could be updated to HTML 5 - and it doesn't make us look up to date when we don't have HTML5 in our exmaples. Would be a great contribution to have folks that could update those to HTML5

<AWK> https://www.w3.org/WAI/GL/wiki/Working_Group_Techniques_Development_Assignments

AWK: This url is where we have tracked this in the past (needed technique work)

<jon_avila> I don't think our aside technique never got finished.

AWK: Similarly, if you found some techniques on your own, throw an item on this page indicating the work you're going to help out with

trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-03-24 16:25:19 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/JC:/JOC:/
Succeeded: s/it is/ as it/
Succeeded: s/still be normative/still be non-normative/
Found Scribe: marcjohlic
Inferring ScribeNick: marcjohlic
Default Present: AWK, Joshue, Kathy_Wahlbin, +1.650.464.aaaa, EricE, Marc_Johlic, Dan, Katie_Haritos-Shea, Mike_Elledge, jon_avila, Michael_Cooper, Loretta_Guarino_Reid, Kenny, James_Nurthen
Present: AWK Joshue Kathy_Wahlbin +1.650.464.aaaa EricE Marc_Johlic Dan Katie_Haritos-Shea Mike_Elledge jon_avila Michael_Cooper Loretta_Guarino_Reid Kenny James_Nurthen
Found Date: 24 Mar 2015
Guessing minutes URL: http://www.w3.org/2015/03/24-wai-wcag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]