HTML Accessibility Task Force Teleconference -- 16 Jun 2011

<trackbot> Date: 16 June 2011

<MikeSmith> scribe: Stevef

proposing additional conformance rules for figcaption as alt. text

JS: chairs decision if no alt then use figcaption
... wait a minute we haven't considered when figcaption may not be appropraite
... only heuristic is if its too long, then not a good fallback for alt

<MichaelC> agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2011Jun/0145.html

JS: can conformance help by defining an upper limit for caption length

JB: from research i have been doing on it the instances in which you will get much longer captions is scientific publications
... when i look at the html5 spec they have not contemplated on how figcaption is going to be used
... diverse types of usage not addrerssed, only some are suitable for alt fallback
... is there a heuristic that could be used so validity is not automatically conferred

<janina> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5.html

JB: in certain kinds of scientific publications the figcaption content was not suitab;e

<Zakim> MikeSmith, you wanted to ask for a pointer to guidance that states that text equivalents should be brief

<MikeSmith> scribe: MikeSmith

Stevef: there's not a prescribed length -- not a hard-and-fast rule, as far as I know

… when an AT user is in this situation, they don't want paragraphs of text read out

… one thing I read recently … 75 to 100 characters is one that people have said is a reasonable length

… so a flag could be added -- be if so, it's useful for more than the figcaption case -- it could just as well apply to the actual alt attribute values

… anyway, figcaption text should be read out with an indication that it's coming from a figure caption

… one of the benefits of figcaption is that it's an element and it can have a role

… to the 2nd point that judy made

judy: that was about the appropriateness

… some figure captions do not provide what you would want as alternative text for the image

Stevef: the advantage of a caption is that the caption does not have to all be read out

… imaginable that user can stop the reading of that, unlike for reading out of the accessible name

<scribe> scribe: Stevef

JS: whether we want an flag on alt is a second question

<Zakim> janina, you wanted to say I don't think we have a consensus on that yet. We're talking about heuristically determined fallback, not intentional quthoring

<Zakim> JF, you wanted to say that much of this sounds like authoring issues

JS: this figcaption is not appropriate so it should be used while a 1000 word caption should not be used

JF: its an authroing question, times when its apprpaiate, other times it could be abused, if we can put in a marker to flag a long caption
... thought it was the flickr new case

flickr use case

JB: i have not been saying figcaption should be thrown out, but should work for users across a broad range of different types of figure captions

<MikeSmith> scribe: MikeSmith

<richardschwerdtfe> BRB

Stevef: figcaption may at some points be an adequate alternative, and many times it may not

… I would not be averse to having a warning being emitted if figcaption is there but alt is not

<scribe> scribe: Stevef

JS: there is not we can do on the authoring side, what happens when the authroing is suboptimal
... if we flagged anything over 200 words we would be doing something useful

MS: is completely doable in conformance checkers
... but in order to add it we need a conformance constraint in the spec
... while en mitting warnings is discretionary

<JF> +1 to experimenting with warning

<Zakim> MikeSmith, you wanted to say that it seems like even many values that casual/naive authors put into alt on img might also not actually be appropriate as text equivalents

<MikeSmith> Stevef: yeah, it's also a concern for the alt attribute

MS: we could try it out experimentally, but come to some kind of decision about what the character limit should be
... its easier to do it for an attribute value, eihter way its not a lot of work

JB: whats the diffrence between a warning and an error, if its not included in the spec as a requirement then it would be better to be an error

MS: need a normative statement somewhere, would be better in the HTMl5 spec
... but could be from another document

JB: go for what is better, needs to be attached to the figcaption

MS: getting something done sooner rather than later could add warning now

JB: what we are looking at is the different parts of the alt text vlaidation decision
... and are entertaining filing a re-open request
... if have consensus then want to reopen

JS: user agents do a specific thing when the user agent does not find an alt so thens uses figcaption

MS: as far as the part of the spec effecetd by the working group decision

<MikeSmith> http://dev.w3.org/html5/spec/embedded-content-1.html#guidance-for-conformance-checkers

<MikeSmith> Stevef: yeah, none of the information for how UAs should handle this are in the spec now… which is part of the reason what I wrote up the API mappings doc

<MikeSmith> Stevef: one thing we should be doing is describing what should happen in this instance as far as a browser behavior is concerned -- how to sensibly map figcaption

<MikeSmith> Stevef: there is the case where it should just be ignored

JF: you said something ealrier, about taking figcaption and dumping it in as alt text

JS: but it sounds like it uses as an alt
... something is better than nothing

JF: no illusions that its is alt but its some text associated with the image
... agrees with the idea about a warning
... figcaption is like a special paragraph, a screen reader will read it out the same as it reads a p

stevef: much lost sorry

MS: from the autthroing side, this is what we have warnings for, thats why it seems difficult to make it a strict error case
... i wanted to get back to saying is from the UA behaviour side, its not in the html5 spec, but nothing similar

<MikeSmith> Stevef: yeah, that is the intention for these sort of things

<MikeSmith> … to at least give some sort of indication about how it should work

<MikeSmith> … I've talked to David Bolter about some this already

<MikeSmith> … I understand the difference that Janina is talking about

<MikeSmith> … the figcaption case gives users greater control

<MikeSmith> … for one, instead of reading out the caption automatically, it could just indicate that alternative text is available in the caption, and asking if the user wants it read out

<MikeSmith> Stevef: ultimately, this guidance should be coming from WAI

MS: almost out of time, has been useful biut won't get much resolution from this today, so take it to the mailing list and I can then implement something experimental in the conformance checker
... we wnated to remind everbody that a number of people have been assigned review tasks for the last call working drafts!

<MikeSmith> http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review

JS: need people to start getting reviews in

deadline mid july

<MikeSmith> janina: need review comments by mid-July but want people to start getting comments in sooner, instead of all at once in July

<janina> scribe: janina

<MikeSmith> comments on section 3.5 from Cynthia: http://lists.w3.org/Archives/Public/public-html-a11y/2011Jun/0120.html

<MikeSmith> adjourned

- DRAFT -

HTML Accessibility Task Force Teleconference

16 Jun 2011

Attendees

Contents

proposing additional conformance rules for figcaption as alt. text

Summary of Action Items

Scribe.perl diagnostic output