Web Content Accessibility Guidelines Working Group Teleconference -- 20 Feb 2014

<trackbot> Date: 20 February 2014

<Loretta> akim, Google is Loretta

<AWK> Chair: AWK

discuss ARIA10/F65 https://www.w3.org/2002/09/wbs/35422/imagediscussmtg/results

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

<AWK> We need a scribe

<Ryladog> https://www.w3.org/WAI/GL/wiki/Scribe_List

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

<AWK> Scribe: James

<Joshue108> +q

KHS: Value of having alt there is because some tools don't support aria-labelledby and aria-label

<adam_solomon> +q

<Ryladog> Alt works for most users who are PWD including those who do and do not use AT

JA: I like the idea of aria-labelledby is that generally the text is on screen. Think this is positive. Generally not supportive of aria-label as much as we already have alt. I beleive alt text should be available to low-vision users and users with cognitive imparments
... title I am very much against as the html spec says it is advisory information for these elements.
... this is pretty much it

<Ryladog> +1 ti title comment by A

<Ryladog> JA

JA: if i had to pick a choice - i would side with something which didn't require aly
... I would like to see a matrix of current support. Would like to see all the possible cases
... just testing an image may not be the same as testing an image inside a link

AK: Stefan not on the call

JOC: wanted to frame the discussion. For me there are a lot of issues in this. One of the reasonds aria10 came to our attention is places where it is not possible to use alt

AS: Q? Is tools not supporting aria-labelledby only an issue for images or is it for everything

KHS: It is not supported in general. It is s a limited set oif configurations today
... what we want to do is support aria but without dropiing support for other things

<Joshue108> +q

KHS: want to continue using alt along with aria-label and aria-labelledby
... perhaps dropping in the future

AS: accoridng to that should we also consider for other techniques

AWK: interesting question and a large can of worms

JOC: really all should try to rememebr that one of the reasons we are having this discussion is want to be able to expand beyond screen reader use. We are in a fuzzy area with poor accessibility support for other than screen readers. Need a little bit of leeway for this discussion

<Joshue108> AWK: To add to Joshs framing, is we are trying to figure out the classic a11y support question

AWK: key question is the classic accessibility support question. When is a technology sufficientlyready?
... easy when you have something that works everywhere all the time
... NVDA have indicated that they will have fixes by their may release on IE.
... if we put the same level of thought to some things we might be suprised at the level of support we see
... part of the reason that the E&O WG suggested we provide strong cautionary statements
... there is a question about how technology gets built - if folks want to experiment then they can

KHS: I agree we want to pus the adoption of aria. I believe we can't do this at the expense of basic access
... I believe we should be concerned about accessibility support
... this is a very basic accessi bility sompoonent

<Zakim> jamesn, you wanted to ask where the support isn't there?

<Joshue108> +q I also disagree with this killing alt

<Joshue108> JN: Where else is support lacking?

KHS: going to be doing a hackathon at CSUN

<Joshue108> JN: I'm still not hearing specifics

<Jon_Avila> I can speak

<Joshue108> JN: So, are people complaining? Regarding SRs, I understand alt not being displayed with images off.

<Joshue108> JN: Aside from that where is support lacking?

AWK: one of the things that is worth thinking about too is are there uses of web technology where there is very solid support.
... for example when creating a mobile application on iOS or Android - the support seems very very solid
... some issues with IE10 + JAWS13 - but later versions of jAWS seem to be doing better

<Ryladog> Related to someones comment that we SHOULDNT be worried about accessibility support, working group is tracking the accessibility support status of techniques, which is not an appropriate expectation to be setting." I think we absolutly *do* need to do this - it is why we update the techniques/understanding as new technologies are coming on board. If we do it for technologies - that means we include OS/UA/and*AT*.

AWK: KHS comment that is it the role of the WG to be tracking accessibility support. My concern is that it is a tremendous amount of work to do that

<Joshue108> +1 to Ryladog

AWK: developers should be paying attention to accessibility support on their project and to make compiance statement based on that
... may be a better use of our time to encourage developers to make wise decisions

<Zakim> Loretta, you wanted to disagree that this kills alt

KHS: why don't we just leave stuff alone rather than update stuff.

LGR: we generally don't update stuff like this

KHS: if we release something tomorrow that does not require alt will some people not have to pay to upgrade?

<Zakim> Joshue, you wanted to say I also disagree with this killing alt

<AWK> Loretta and Josh say that they don't think that this is about killing alt

LGR & JOC: want to say that we are not killing alt

JOC: may be cases where aria is a better solution and alt is not possible
... user agent support. Something we should be doing but who is going to do it. The accessibility support DB from Shadi may do some of this work. Once that is there it is an option which may work

KHS: agree that i don't see people killing alt
... people being left behind bothers me

<Joshue108> JN: My aim is to ensure that people aren't penalised if they have done things that work.

<Joshue108> JN: Its more important to make the failure work - I'd be happy if something doesn't fail if they have provided an accessible name, without provision of a positive technique.

AWK: <reads Stefan Schnabel comments>

LGR: I think Stefan is arguing that we should be allowing aria and not casting something in stone which would obstruct this

<Joshue108> JN: Yes

<Joshue108> JN: @alt is still required in HTML.

AWK: validating for WCAG is a differnt check
... kerstin's comment is that aria is a good thing and the price here is too high

KP: did some screen reader testing today with NVDA + IE11 and support not there

AWK: NVDA + IE is not a very common use case
... Jamie stated they will have this fixed by May
... if you say should it means doesn't have to

KA: it is the "in addition to" instead of "instead of"
... if i were to rewite I would change the word should

AWK: Alastair is suggesting being more conservative
... Sailesh also in support of option 1 - requiring alt eith minor edits
... answers to questions
... point 1 - no it doesn't
... point 2 - agree this seems to need changing
... point 3 - find that confusing

LGR: 2 parts. Is there accessibility support or is there not
... I understand the motivation to explain what the WG is thinking but should keep the WG out of the techniques
... discussion about a11y support belongs in the UA notes
... if we want to require alt on the elements which support alt then we may want to break this in half
... should perhaps put more explanation about these in here

<Joshue108> +q

LGR: if we do that then labelledby with an image becomes advisroy becuase we are saying it is not sufficient
... even if we look at the current state of things there are people with older versions

KHS: this is vital

LGR: i would hope all the wcag techniques are vital
... here there is an easy alternative and others may not have them
... If we say they must provide alt then authors will not provide aria-labelledby as there is no point in them doing so

JOC: I am very concerned about things I see in my day job. Very concerned that some of the good stuff I see aria can do gets put into advisory. I would sit on the side of taking a chance with this. I would try to push to support aria. Maybe not in this iteration

KHS: I have no interest in not supporting aria but want to additionaly require alt

LGR: don't need to. Doesn't improve accessibility

KHS: allows the adoption of aria and allows backwards compatibility

AWK: would agree that having both doesn't increase accessibility. Will make AT vendors look and see that they don't need to pay attention to aria-labelledby as there is always alt

<Ryladog> If the understanding by *all* is that ALT will be retired than tool makeers and devlopers can build their stuff appropriately

AWK: someone that is creating a site or an application is supposed to do their due diligence. May mean allowing people to do things we are not thrilled about today

LGR: would be willing to go down a 2 use cases
... would really like to modify the failure such that aria-labelledby is ok provided it is accessibility supported

KHS: leaves door open.
... the failure - don't agree with the fact that AT vendors will not implement things if we make it very clear that tthe requirement for alt will be removed

<Joshue108> JN: I think the failure has to be changed.

<Joshue108> JN: For in intranet only app, or a packaged solution, why would they have a failure when their configurations are supported?

<Joshue108> RD: It wouldn't be

<Joshue108> JN: Sorry

<Joshue108> RD: How is a tool going to be able to determine that?

<Joshue108> JN: I don't understand, this is a failure. In my job, we sell a product, and will only support certain configurations.

<Joshue108> JN: If all platforms we support, and our clients say you fail this failure, and you fail WCAG?

<Joshue108> RD: Right, we need a safety valve for where it isn't a controlled environment

KHS: I want to make sure there is a safety valve for when things aren't in a controlled environment

<Joshue108> RD: How can we do that?

LGR: want to add a check in the failure to make sure that something is accessibility supported

<Joshue108> JN: Do you recall I sent a proposal for this, AWK?

<Joshue108> AWK: No

<Joshue108> JN: I'll have a look

<Joshue108> JN: It's what Loretta is suggesting

https://www.w3.org/WAI/GL/wiki/F65_Round_2#Example_1:_Missing_alt_text

<Joshue108> JN: It's similar to what Loretta is suggesting

<Joshue108> +q

LGR: having nothing about labelledby in a positive way for these elements

<Joshue108> -q

<Joshue108> +q to say being very cautious with our techs and failures may be the way to crack this

<Joshue108> RD: Support and access to the a11y API has to be considered.

<Joshue108> JN: Yes

<Joshue108> JN: This is failure, if this is being shown to the A11y API, then it's not a failure!

<Joshue108> AWK: Right

<Joshue108> LGR: Failure were meant to highlight common things people were doing wrong

<Joshue108> LGR: Not capture everything

<Zakim> Joshue, you wanted to say being very cautious with our techs and failures may be the way to crack this

<Loretta> Looking at https://www.w3.org/WAI/GL/wiki/Aria-Edit:_F65:_Failure_of_Success_Criterion_1.1.1_due_to_omitting_the_alt_attribute_on_img_elements,_area_elements,_and_input_elements_of_type_image#Description, I propose change steps 1, 2, and 4 to something like:

JOC: people will say we can only use wcag technqieus perhaps something we want to break
... should we be erring on extreme caution or should we be pushing the envelope a bit

<Loretta> 1. check if aria-labelledby references one or more id elements in the page AND that aria-labelledby is accessibility supported for the target audience

AWK: mandate as part of the procedure step that this is accessibility supported

LGR: not just view the API

KHS: also needs to be explanation in the top part as to why this is necessary

<AWK> Loretta's suggestion is on F65

LGR: accessibility support implies that you undersand waht versions of browsers and what AT your target audience is using
... this goes back to JN example where they know the answers to these questions

KHS: then Katie's concern that in the wild west these answers may not be known

<kerstin_probiesch> and we should add a note about what "target audience" means: intranet, closed environments

<Joshue108> JN: Is this a slippy slope?

<Joshue108> JN: Is it a can of worms?

<Joshue108> LGR: Yes

<Joshue108> JN: Why do this in this case but not in others?

<Joshue108> LGR: Do we have failures for those situations?

<Joshue108> LGR: But is there a documented failure?

<Joshue108> JN: I think there is

<Joshue108> LGR: Maybe we need to look at modification to failures.

<Jon_Avila> I don't see any 1.3.1 failures for label of label or title

JA: wanted to bring up title being allowed
... wanted to know if i am the only one concerned

JOC: it is one of the things that it is looked at

<Joshue108> JN: It's in the API mappings doc etc

<Joshue108> JN: Its defined in the HTML5 API doc

<Joshue108> JA: But its in an advisory tech, is that valid?

<Joshue108> JN: I don't care about validity, but am more concerend about a11y support

http://www.w3.org/TR/html-aapi/#img-element

<Joshue108> JOC: @title could come back better support in VoiceOver

AWK: are we getting to a spot where we can agree
... if the procedure reinforces that a11y support necessary then that may be satisfactory

LGR: my comments were for F65

<Joshue108> ACTION: Loretta to draft changes to F65 and changes to ARIA 10 on elements that have @alt [recorded in http://www.w3.org/2014/02/20-wai-wcag-minutes.html#action01]

<trackbot> Created ACTION-238 - Draft changes to f65 and changes to aria 10 on elements that have @alt [on Loretta Guarino Reid - due 2014-02-27].

<Ryladog> +1

LGR: wanted to make a proposal and volunteer to make these changes to F65 and ARIA10 so we can survey them on Tuesday

AWK: going to have to do that. In terms of if we are trying to hit the CSUN schedule and we can't come to a resolution on this. What do we do then?
... I feel like there is a lot of value in regular techniques. Don't want to turn this into a 2 year technqieus cycle. Want to do somnething to get this out by CSUN. perhaps that means pulling the technqiues
... we can debate this until a11y support improves

<Joshue108> JN: I think a11y support is there in new versions.

<Joshue108> JN: I don't now what 'until a11y support improves'

<Joshue108> LGR: I don't think we can pull F65

<Joshue108> JN: Do you mean pulling the changes?

LGR: I don't think we can pull F65 without notice but could remove ARIA10

<Joshue108> LGR: No, dropping the tech

<Joshue108> LGR: We can't do that without warning

AWK: there may be some procedural steps that need to be taken

KHS: have faith in what LGR is proposing

<kerstin_probiesch> +1

<Joshue108> Zakim

AWK: are we going in a direction that sounds good

yes

<Joshue108> +1 from me

<Joshue108> thanks loretta

<kerstin_probiesch> thanks Loretta

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

20 Feb 2014

Attendees

Contents

discuss ARIA10/F65 https://www.w3.org/2002/09/wbs/35422/imagediscussmtg/results

Summary of Action Items

Scribe.perl diagnostic output