HTML Caucus Draft Minutes for 28 Auguest

Available as html at:
http://www.w3.org/2009/08/28-pf-minutes.html

And as text following ...

   W3C

                                                           - DRAFT -

                                                     PF/HTML_Caucus telecon
                                                          28 Aug 2009

   See also: IRC log

Attendees

   Present
          Rich_Schwerdtfeger, Janina, Stevef, Janina.a, Joshue, Gez, Katie_Haritos-Shea, cyns, +49.179.103.aaaa, kliehm,
          Cooper, +1.218.340.aabb

   Regrets
   Chair
          Janina_Sajka

   Scribe
          Gez

Contents

     * Topics
     * Summary of Action Items
     __________________________________________________________________________________________________________________



   <richardschwerdtfe> Steve, you need to move to the U.S.

   <richardschwerdtfe> :-)

   <Stevef> rich: i couldn't live in a country that does not have universal healthcare

   <Joshue> :-)

   <janina> agenda: this

   <richardschwerdtfe> scribe: Gez

   JS: Outstanding issues in HTML?

   RS: Mike is going to look into issues about IP issues between the two groups
   ... People can join both groups, but some people might not want to join
   ... Joining the HTML WG doesn't mean you have to get involved in all the arguments

   JS: The three HTML chairs are moving things forward. I would have thought they would have ironed out the issues with IP
   with the WHATWG, unless there is something I haven't heard about.
   ... If there is any ambiguity, it's more an issue from their side than ours. The whole point of a task force is to
   avoid these issues

   RS: Steve Faulkner raised concerns about browser being able to OCR image in markup and provide adequate alt text.
   Suggested it be struck, wich RS CS support
   ... Canvas call today

   JS: anyone else have an update?

   <richardschwerdtfe> http://www.w3.org/Guide/1998/08/teleconference-calendar.html#s_3719

   <richardschwerdtfe> WAI_PFWG(CANVAS)

   <richardschwerdtfe> WAI Protocols & Formats WG

   <richardschwerdtfe> Friday, 28 August 18:00-19:00 UTC (2:00pm-3:00pm Boston local)

   <richardschwerdtfe> Zakim Bridge +1.617.761.6200, conference 92473 ("WAIPF")

   <richardschwerdtfe> 13 participants

   <richardschwerdtfe> Mike Smith <mike@w3.org>

   <Stevef> matt may rasied issue of OCR

   <richardschwerdtfe> yes

   CS: Asked Steve Faulkner to come to the API call today.

   <Stevef> will be able tyo attend first 1/2 hour if my internet connection speeds up

   <Stevef> of the API meet that is

   RS: Chuck has offered to help with editing

   JS: Editors need to be HTML WG members
   ... Issue of moving meetings times around. Can you take it up on the API call today

   CS: I thought Wednesday would work

   JS: If API and this meeting swapped, that could work too
   ... Talk about the email conversations around alt

   <Stevef> no am only on IRC

   SF: There are a couple of main issues with the document as it is, that revolve around the use of aria-labelledby
   ... aria-labelledby is problematic

   RS: Why would you use aria-labelledby without an alt?

   SF: That's been put forward as a valid alternative to alt

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

   SF: One of the ways image can be valid is with aria-labelledby
   ... People have questioned what happens when aria-labelledby isn't provided, such as a text only browser
   ... I think it's a valid point, and not a good basis for providing a text alternative

   RS: What about title?

   SF: in the concensus document, we haven't mentioned title, but the HTML5 document mentions title as being conforming
   ... But the issue with title is that it's not rendered
   ... If a title is provided without alt, AT might report it, but not regular text based user agents

   RS: As they already have title, is there a reason they didn't want to have all images require the browser to show the
   title?

   CS: The problem with title and alt display on hover is that text that displays on hover generally doesn't make good alt
   text
   ... People should use title for tooltips

   JS: Legacy browser will have trouble with HTML5 no matter what

   CS: Yes

   RS: Cynthia, have you conveyed that to the HTML WG?

   CS: No, but that's how it works previously

   SF: The issue is more about what's considered a valid point
   ... It's not saying that the text alternative for the image is necessary the image, it's just it has a visually
   associated caption. It's not saying best practice, but bare minimum

   CS: Worried about title being valid

   RS: We have aria-labelledby, which can be used other places. Why not use aria-labelledby and ditch alt attribute
   ... Why not simplify it and use aria-labelledby?

   <Laura> The title attribute represents advisory information for the element, such as would be appropriate for a
   tooltip.

   <Laura> http://www.w3.org/TR/html5/dom.html#the-title-attribute

   SF: That wouldn't fly, as alt is well defined

   RS: There are so many different things in HTML5, why not use aria-labelledby as a better mechanism

   JS: Let's just drop alt, as so much is going to be new, we'll have so much to clear up in the accessibility community.
   The consensus as putting it in as a alternative is a good way to introduce moving in a new direction. We don't need
   both mechanisms

   <Joshue> JOC: Rich makes a good point, do we want to make these kind of disruptive but maybe in the long run -
   beneficial leaps?

   CS: alt is widely deployed (paving cowpath)

   <Joshue> GL: I may be missing the point here but using aria-labelled by you have to have the text within the content,
   so I would see a problem using both techniques

   RS: Not aria-labelledby; use aria-label as a single method
   ... If you want to use a summary, you can use aria-describedby - even if it's hidden, it gets mapped to accessibility
   architecture
   ... Not having alt, label, and title simplifies what the browser has to do

   MC: A big thing about alt is that there's a lot of legacy content that won't get updated

   MS: Not oppose a new mechanism, but it's not simple to remove it

   JS: Agree with Janina and Michael; politically, it would cause too many problems

   <Joshue> +q

   RS: If you look at HTML5, what's legacy? They have so many new features; it doesn't make sense

   CS: Browsers don't make the distinction of what they're rendering
   ... If a browser uses tag soup with label it would render if it is supported by the browser
   ... Validation versus what should happen in the browser is not going to make it easier for browser

   <Zakim> MichaelC, you wanted to say there is a huge amount of legacy content that will never be updated - alt needs to
   continue to be supported - though I support new features as well

   SF: The discussion is about WAI CG putting forward a consensus document, and people are disagreeing with aria-label as
   a method
   ... role="presentation" and alt="" should be the same thing

   RS: role="presentation" takes the image out of the accessibility layer. In situations where a blind user wanted to
   access the image, they wouldn't be able to get it because it's completely removed. Whereas alt="" is still exposed as a
   graphic in the accessibility architecture

   JOC: What's wrong with that?

   SF: Nothing wrong with it; role="presentation" should not be the same as an empty alt
   ... If they're curious, they could read the source
   ... An image of a chart - if that content is available elsewhere, people put alt="" to hide from AT
   ... Or role="presentation", so the argument is that's not a presentational image. The image contains information. A
   user should know the graphic is there and that it contains information

   JS: Would alt="" be appropriate on a chart?

   SF: Not according to WCAG 2 (my reading). The image should have a text alternative to describe at least what the image
   is

   JS: Exactly; it's not presentation, so the argument doesn't make sense

   SF: HTML5 advise to put empty alt

   JS: Good reason why HTML5 shouldn't advise on alt text, and refer to WCAG instead

   SF: I'm not making these points; I'm relaying the issues that have been discussed

   JS: we need to understand what's burning and can help on some of these issues

   SF: Long text alternatives were not discussed
   ... There is a section on recommending long text alternatives to replace longdesc, but no one mentioned it
   ... They're ignoring it
   ... Something to remember: the spec is not going to change as Ian has decided not to respond to the document, as he
   doesn't understand the rationale
   ... Ian's one statement is that ARIA should be used as a last resort

   <Joshue> JOC: Does the ARIA part of the spec not have parity with the rest of the spec?

   JOC: If an image contains aria-label, it's an equivalent of an alt, and should be considered fine

   <Joshue> -q

   CS: It sounds like there is a discussion about whether Opera or IE is right in their approach

   <Zakim> cyns, you wanted to say that alt="" takes the image out of the accessibiltiy tree in Opera and (I think)
   Firefox. The behavior you're describing (leaving in the the role=graphic)

   CS: Both are done out in the world, and we can talk to AT vendors about which works better
   ... WCAG 2.0 could have techniques for HTML5 + ARIA

   MC: alt="" on a chart wouldn't conform to WCAG, but we don't need HTML to force WCAG conformance; it just needs to
   support it

   <Zakim> MichaelC, you wanted to say we don't need HTML to enforce WCAG 2 - we just need it to make it possible for
   authors to meet WCAG 2

   <Joshue> +1 to Michael that the language should enable conformance to WCAG, the details of how this are done are moot,
   and actually changing all the time as technologies progress.

   RS: HTML5 want to use ARIA as a last resort; if there's no additional work in making something in HTML, that's a good
   thing.

   JS: If something isn't a last call comment, it's something we can judge. We have some comments that aren't properly
   comments on our specs, but things we need to be aware of

   <Joshue> +q

   <Laura> Inviting Ian to a telco is a good Idea.

   JS: All of us may have a slightly different spin on what's in the consensus document, but what we have is the approach
   that got the widest acceptance. We should remind HTML5 WG of that fact

   <richardschwerdtfe> aria-label

   JS: Maybe some of us could jump into this thread and clarify this

   JOC: Do the HTML5 WG not agree with the consensus document?

   SF: Yes
   ... Part of the thread was between Henri and Jan Richards, who appear to have come to some agreement

   JOC: It's important not to get drawn into arguments when we have consensus

   <Joshue> -q

   JS: One of the reasons we're looking for additional editors is that if Ian, for whatever reason, cannot contribute
   text, we have someone that can do it

   CS: Be cautious of modelling consensus based decision as an effective process
   ... There are two editors for HTML5 on this call (me and Steve)
   ... But prefer Ian to do it

   <Zakim> cyns, you wanted to say that one of the things we should be doing in this group is modeling consensus
   decsion-making. rehashing our consensus is not really the best way to do

   RS: Sam has asked me to do the edit, so I would rather not be dependent on Ian
   ... We need to be more proactive

   JS: It would give us a better debating point for moving forwards
   ... We need someone to turn it into spec language

   RS: Ian's asking mapping questions for ARIA, and one of the issues is alt="" and role="presentation"

Summary of Action Items

   [End of minutes]

-- 

Janina Sajka,	Phone:	+1.202.595.7777;
		sip:janina@CapitalAccessibility.Com
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

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 Friday, 28 August 2009 15:09:14 UTC