TF Teleconference Minutes for 16 June

Minutes from the HTML-A11y Task Force teleconference on 16 June are
provided as text below, and are available as hypertext at:

http://www.w3.org/2011/06/16-html-a11y-minutes.html

   W3C

                                                           - DRAFT -

                                          HTML Accessibility Task Force Teleconference

16 Jun 2011

   Agenda

   See also: IRC log

Attendees

   Present
          John_Foliot, Janina_Sajka, Mike, Judy, Lynn_Holdsworth, Rich_Schwerdtfeger, Steve, Marco_Ranon, Michael_Cooper

   Regrets
   Chair
          SV_MEETING_CHAIR

   Scribe
          Stevef, MikeSmith, janina

Contents

     * Topics
         1. proposing additional conformance rules for figcaption as alt. text
     * Summary of Action Items
     __________________________________________________________________________________________________________________

   <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

Summary of Action Items

   [End of minutes]
     __________________________________________________________________________________________________________________

Scribes: Stevef, MikeSmith, janina
Present: John_Foliot Janina_Sajka Mike Judy Lynn_Holdsworth Rich_Schwerdtfeger Steve Marco_Ranon Michael_Cooper

-- 

Janina Sajka, Phone: +1.443.300.2200
  sip:janina@asterisk.rednote.net

Chair, Open Accessibility janina@a11y.org 
Linux Foundation  http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Thursday, 16 June 2011 16:11:05 UTC