HTML Accessibility Task Force Teleconference -- 19 Mar 2011

<trackbot> Date: 19 March 2011

<richardschwerdtfe> Hi Gregory

<dboudreau> hi everyone

<dboudreau> greg! ça va bien?

<Zakim> oedipus, you wanted to ask if breakout session will use #html-a11y-media or #html-a11y-2 ?

<oedipus> thought for the day: "It is much easier to slip into a daydream than it is to think." -- Charles Willeford ("I Was Looking for a Street")

<lwatson> scribe: lwatson

<oedipus> scribenick: lwatson

<oedipus> need both longdesc (external reference) and describedby (in-document reference)

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

<oedipus> a company or organization might have a collection of clip art for use in site, with pre-canned ALT text and stable LONGDESC reference which can be re-used ad infinitum

<oedipus> central control over images and image description

Text alternatives

SF: Issue 30 is being surveyed ATM.

JS We have given our recommendations on 80, 122 and 31.

<oedipus> lady of shallot: http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/

JS: The question is whether we're satisfied with this, and whether the right supporting points have been made?

<oedipus> GJR's change proposal is survey question 3

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

<oedipus> TF proposal from TPAC: http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/thematicimages

<oedipus> GJR's proposal reflects consensus reached at TPAC 2010 F2F of A11y TF

<oedipus> TF proposal from TPAC: http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

SF: There is a response from me because the riginal bug was filed against the alt text document, that required a change proposal.
... The chairs wanted to widen the scope, so the same message was given across the spec and the alt text document.

<oedipus> lady of shallot issue statement: http://www.w3.org/html/wg/tracker/issues/122

<oedipus> HTML WG ACTION 195 (propose replacement text) http://www.w3.org/html/wg/tracker/actions/195

SF: There is an example of using an img of the Lady of Shallot. The page contains the poem of the same name. The spec suggests the image is therefore decorative, but the alt text doc says otherwise because it adds to the thematic information.
... It shouldn't be mandidated that you can't provide an alternative text.

RS: You have short names and long descriptions. There are different vehicles for providing the short.

JS: To keep this in context, two years ago when we came up with our consensus guidance we said there should be supporting documentation and that it should coe rom WAI.

JB: Within the WAI co-ordination group, we spoke about getting this moved to the WCAG WG. BTW, there is also work being started on this by an external organisation that may result in confusion.

SF: The alt text document was developed to counter the normative advice given within the spec.

<oedipus> GJR replacement text paragraph 1: "If an image is decorative but isn't especially page-specific -- for example, an image that forms part of a site-wide design scheme -- the image should be specified in the site's or document's CSS, not in the markup of the document."

<oedipus> GJR replacement text paragraph 2: "Exceptions to this rule, in cases where CSS cannot be used to display an entirely decorative image, are covered by the HTML5: Techniques for providing useful text alternatives. [HTML ALT TECHS] Authors are also encouraged to consult the Web Content Accessibility Guidelines 2.0 for more detailed information and acceptable techniques. [WCAG 2.0] "

SF: If we move the alt text doc out to WCAG, we need a pointer within the HTML5 spec.

<oedipus> steve, that is what my CP provides

SF: The main issue I'm concerned about, is that the advice in the HTML5 spec is not authoratative.

<oedipus> HTML5 should point to WCAG as per my change proposal

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

SF: Text alternatives are for more than people with disabilities.

JF: It's not who benefits, but where the guidance comes from.

SF: I would be more than happy if the guidance was maintained outside of the HTML5 spec.

RS: When you put alt="" the spec should advice what the UA does with it.

<dboudreau> I agree with you Greg. There should be a direct link from the spec to WCAG

SF: It' the normative authoring advice that needs looking at.

RS: If an image has role=presentation should the rendering be the same?

SF: Alt="" should be the same as role=presentation.

<oedipus> related: CP for definition of image (also agreed-to at TPAC 2010: http://www.w3.org/html/wg/wiki/ChangeProposals/first_2_paragraphs_of_definition_of_img

<oedipus> my objection to role="presentation" was based on the fact that HTML5 lacked a role attribute -- now we have one, no?

<Zakim> oedipus, you wanted to say that my change proposal points to WCAG and SteveF's alt techs document for discussion of purely decorative images after stating that should be controlled

RS: We could propose advice for UA as to what should happen when images are turned off.

<richardschwerdtfe> yes, we will have a role attribute after our discussion today. ... lexical processing of ARIA section

<oedipus> then i'm ok with role="presentation"

<Joshue> I think we turned a wrong corner when there couldn't even be a consensus that image would have the role="image".

<oedipus> CP for definition of image (also agreed-to at TPAC 2010: http://www.w3.org/html/wg/wiki/ChangeProposals/first_2_paragraphs_of_definition_of_img

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/purely_decorative_images

MS: Not sure what Laura's position on this actually is. It would be good if she could join the call.

<Joshue> We meaning them (sic) and us (sic)

MS: Perhaps we should postpone discussion on this until Laura is here.

JB: We probably souldn't hold up progress on this, as Laura may not be able to make it.

<MikeSmith> http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/results

<MikeSmith> http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/

<MikeSmith> heh

JS: We previously voted GJR's proposal.
... Which leaves a second question of where this document/guidance lives.

<oedipus> correct -- we decided at TPAC what to say, and i was tasked to write it up as a ChangeProposal

SF: We were previously talking about role=presentation. James Craig says this isn't appropriate, as per the ARIA spec.

JC: Is this just about where this document lives?

<Joshue> -q

CS: So the TF has a position on which position we go with?

<oedipus> can someone type cyns' question into IRC

<oedipus> ACTION: Gregory - submit comments on behalf of TF to http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/ - due 2011-03-24 [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-110 - - submit comments on behalf of TF to http://www.w3.org/2002/09/wbs/40318/issue-122-objection-poll/ [on Gregory Rosmaita - due 2011-03-24].

JS: Is there anything else we need to say here on alt, before we move on?

<MikeSmith> yep

SF: We seem to be in agreement, but my one concern is that the change materials the chairs will be reviewing doesn't necessarily reflect the clarity we need.

SP: If someone has a decorative image, what's the recommended approach?

<oedipus> Stevef, what additions do you deem necessary to the change proposal for 122?

JF: It's a contextual answr, given in some detail in the spec.

<oedipus> GJR proposal says: if purely decorative, use CSS; if can't use CSS, consult WCAG 2.0

SF: If it's purely decorative, then give it a null alt.

<oedipus> if purely decorative, use CSS to embed image

<JF> http://www.w3.org/TR/wai-aria/roles#presentation

<dboudreau> http://www.w3.org/TR/wai-aria/roles#presentation

<oedipus> if allow liberal use of <img src-"foo.jpg" role="presentation"> will be offering an intollerable escape clause -- purely decorative images should be handled via CSS and only with role="presentation" in circumstances where CSS is not available

RS: role=presentation seems cleaner to me.

JF: We'll need to keep alt="" for backwards compatibility.

CS: We'll need both for at least the next five years or so.

<oedipus> need to say for "redundant" images (such as a mailbox and the hypertext string "email us!" then the image can be role="presentation" or alt="" but that is the only compelling case for not using CSS for images (and even then, if an author is smart, he/she can do this with CSS anyway)

DB: Is there a risk to using role=presentation that we'll need to use role=information for images that are not decorative?

JS: It's presumed, so we probably wouldn't need to.

CS: That was a point of contention at one point, but has since been settled.

SF: JC raised a question about alt="" and role=presentation. The spec says if a decorative image with role=presentation is encountered, remove it from the accessibility tree.

JS: What's the advice going forward?

SF: That *is the advice, and we haven't questioned this so far.

<Zakim> oedipus, you wanted to ask why aren't we saying use CSS to control purely decorative images?

GJR: Why are we saying use CSS to control purely decorative images?
... We should say use CSS for decorative images full stop.

DB: You can't always do that.

<oedipus> janina, GJR replacement text paragraph 1: "If an image is decorative but isn't especially page-specific -- for example, an image that forms part of a site-wide design scheme -- the image should be specified in the site's or document's CSS, not in the markusp of the document."

<oedipus> janina, GJR replacement text paragraph 2: "Exceptions to this rule, in cases where CSS cannot be used to display an entirely decorative image, are covered by the HTML5: Techniques for providing useful text alternatives. [HTML ALT TECHS] Authors are also encouraged to consult the Web Content Accessibility Guidelines 2.0 for more detailed information and acceptable techniques. [WCAG 2.0] "

MS: This is an issue for the change proposal itself, but with regards to the spec the change proposal is advocating for haing the spec reference some other txt/document.
... It's not an issue in terms of what we need to do for last call. The text we're referencing isn't the issue.

<dboudreau> Greg, there are many situations in which you have no choice but to put your decorative image in the html. I don't think we can enforce that.

<oedipus> dboudreau, the second paragraph says, if you cannot use CSS, then consult Alt Techs and WCAG 2.0

JS: We're dicussing issue 80 ATM.
... We have guidance on 80, the question is whether we stand by this?

<MikeSmith> ack oedipus http://www.w3.org/html/wg/tracker/issues/80

JS: We were against using title, if alt wasn't provied

SF: Don't think there has been any disagreement on this, and we had a poll as well.

<Joshue> ISSUE-80 http://www.w3.org/html/wg/tracker/issues/80

<dboudreau> oh, i see. But then, refering to techniques, we should find a reference to role="presentation" there if this is what we agree on

<MikeSmith> http://www.w3.org/html/wg/tracker/issues/80

<oedipus> dboudreau, yes, definitely --

MS: Issues 80 and 31 are waiting for the chairs.

JS: Do we need to revisit this?

<oedipus> which CP: http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 ??

CS: Our position has been stated, but issue 31 hasn't ben polled. Do we know what the TF position is?

SP: That label isn't a good substitute for alt?

MS: There are a buch of change proposals for issue 31.

SF: We decided to put forward option 3 (perhaps 2) on this.

MS: Laura wasn't in agreement with this. Would be good to have her input here on this.

<oedipus> SteveF, you are talking about http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203 right?

SF: If we're in agreement that the normative advice should be taken out of the spec, our response to 31 should either include or encompass that.

MS: It's a different problem. We do need to have normative text in the spec. This is about the exceptions and what they are.

SF: What should the exception be if you don't have an alt attribute on an image?

MS: In terms of the conformance/validator, what should be an acceptable substitute?

<oedipus> hixie's change proposal for Issue 80 and Issue 31: http://lists.w3.org/Archives/Public/public-html/2010Jul/0050.html

SF: Summary is that it's ok to h have role=presentation, alt="", or a image with no alt and an associated figcaption, or aria-labelledby.

JF: Did we have agreement with that?

SF: Yes, I think we do.

JS: We've discussed this sevral times and have always arrived at the same place. We should mntion this in the survey.

<MichaelC> HTML meeting in Lyon

SP: How does aria-labelledby and title fit into this?

SF: The consensus was that title shouldn't be considered a conforming image, as far as the provision of a text alternative goes.

DB: Is that because ATs don't support both?

CS: We feel it's the right way to do it.

SF: Historically, it hasn't been keyboard accessible - the information might be important. It's a browser limitation, but it's been known about for 10 years or more and there is no srong advice in the spec about providing a text dscription is a device independent way.

JF: When IE started putting tooltips in, the attribute values were often duplicated causing information to be doubled up with some ATs.

<oedipus> @title often contains useful metadata (file type, size, etc.)

CS: In the Lyon/TPAC minutes I can't find an agreement.

<oedipus> dboudreau, definitely need to push screen reader devs to support both alt and title (in JAWS, one can set cascade of attributes to expose)

<oedipus> but need to have a query for title and aria-label

<dboudreau> another problem with @title is that it's a hover effect only (tooltip) therefore useless when using the keyboard only and on mobile

<oedipus> dboudreau, agreed

SF: ARIA has no effect on the UA rendering of stuff. So you display the content of aria-label means you're asking the UA to do something extra. I'm not opposed to that, but that's the reason whay it's not in the spec.

<dboudreau> greg, if we were to push them towards supporting both attributes, then users wold get the info twice... pretty annoying don't you think?

CS: Alt is rendered as a place holder, aria-label isn't.

<dboudreau> unless we could get mechanism that only reads the value of @title when it's different form the @alt's value... but then again, this is just another specific setting available in jaws

<MikeSmith> action Steven to send e-mail message to a11y TF mailing list with a draft summary of the TF consensus position on what exceptions should be allowed for alt-less images (e.g., role=presentation, aria-labeledby, etc.)

<trackbot> Sorry, couldn't find user - Steven

<MikeSmith> action Steve to send e-mail message to a11y TF mailing list with a draft summary of the TF consensus position on what exceptions should be allowed for alt-less images (e.g., role=presentation, aria-labeledby, etc.)

<trackbot> Created ACTION-111 - Send e-mail message to a11y TF mailing list with a draft summary of the TF consensus position on what exceptions should be allowed for alt-less images (e.g., role=presentation, aria-labeledby, etc.) [on Steve Faulkner - due 2011-03-26].

<oedipus> dboudreau, alt needs to be a functional equivalent of the image being described, title is a hint/advice -- when i use both i never use the same text -- validator should mark identical alt and title strings assigned to a single element as an ERROR and instruct the author to either use one or to change the value of one

<oedipus> validator should mark identical alt and title strings assigned to a single element as an ERROR and instruct the author to either use one or to change the value of one

SP: So I'm supposed to use alt as an author, and ignore the rest?

CS: No, they're different things for different situations.

<dboudreau> greg » i like that idea very much. from a validation perspective this is good, but most authors won't validate therefore won't be stopped by this

RS: When you write the overview, could you include somethig about using aria-label?

<dboudreau> so while i do like it, i don't think it will be useful or helpful enough for the end user

<oedipus> dboudreau, so ATAG needs to say "if author enters identical value for @alt and @title, generate an error message and query for different strings (alt for equivalent info, title for extra metadata)

Longdesc

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

<dboudreau> greg, i fail to see how this would prevent authors from abusing both attributes with the same value

JS: There are two questions... Where and what. Let's take them in reverse order.

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Requirements_for_HTML5

JS: I suspect there is consensus within the TF to get longdesc back in the spec.

<oedipus> laura's longdesc research: http://www.d.umn.edu/~lcarlson/research/ld.html

JF: We've heard from lots of people that there needs to be a visual indicator of longdesc, for sighted people who would benefit. Longdesc was originally intended to be hidden. Browsers seem reluctant to do this.

<oedipus> dboudreau, if author using authoring tool, that tool should know to watch for and flag as error identical values for @alt and @title -- sure won't help hand-coders like myself, but we seem to be a dying breed

<oedipus> dboudreau, either that or threaten the author with "cruel and unusal punishment"

JF: Several browser vendors have epressed an interest in creating a visual indicator plugin of some kind.

s/rpressed/expressed/

<oedipus> tools that support LONGDESC: http://www.d.umn.edu/~lcarlson/research/ld.html#tools

<dboudreau> you may be right... but i'd be reluctant to suport this knowing it would end up meaning redundancy for end users.. i'd rather go with the threat and personnaly dliver it myself (if we have the budget) <grin>

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Implementation_Information_for_LONGDESC

<oedipus> dboudreau, my idea would only work with additions to WCAG, ATAG and UAAG (expose all metadata)

JF: If the browsers themselves can't close the loop, perhaps ATs will
... If the browsers themselves can't close the loop, perhaps ATs will?

JB: Can you give some examples of the use case for a visual indicator?

<Joshue> I agree with Judy about use of a @longdesc plugin..not mad about the idea.

<oedipus> longdesc not only for blind -- cognitive users may be assisted by a guide to the complex image as would those with very limited viewports

JF: People with disabilities that mean they would benefit from the additional information held in a longdesc.

<oedipus> longdesc exposure and exposition should NOT be an AT thing, but a UA thing

<Joshue> +1 to GJR

JB: Browser plugins seem like a comprimised way of dealing with this.

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Use_Cases

<dboudreau> I also believe we should work to have longdesc supported by the UA, not the AT... UA means more people can benefit form it

<oedipus> dboudreau, amen, brother!

JB: How much as the TF looked into the use cases?

<Joshue> Longdesc shouldn't be a second class citizen in the browser.

<oedipus> plus 1 to JOC

JB: If one of the reasons the browsers are pushing back is because the use cases aren't strong enough, perhaps the TF should strengthen the case.

<oedipus> judy, laura and i have tried to structure http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs to reflect what the chairs told us they wanted explicated

RS: Rather than a plugin, have you asked the browsers about an option within the settings?

<Joshue> A configurable option in the browser isn't a bad idea. +1 to RS.

JF: The functionality is available through the contextual menu. Screen readers also have a mechanism for giving the user a choice of whether to access the longdesc.

<oedipus> plus 1 as well -- user needs to know longdesc available -- should be able to put images with longdesc into the tab-navigation order so it is easy for the user to access

JF: One of the prolems with longdesc is that developers don't see it, potential cause for longdesc etc. If we make it visible, it has to go in one of two places. A plugin will give us proof of concept.

<oedipus> JF, note that one can only get longdesc info from a graphic if one lets the whole page be spoken or if one navigates from graphic-to-graphic when using screen reader

RS: The concern I have is that the people who need a visual indicator, is that a plugin will be difficult for the people who would most benefit from the functionality.

<oedipus> UA needs to allow users to add images with longdesc to the tab navigation order for the page

<Joshue> +q

RS: Let's put the use case together and explain that the UA should provide a visual indicator.

<oedipus> visual indicator should be an option not a requirement or default setting

JF: Longdesc is a DOM node. As ar as supporting the browsers goes, it's ther. It's what the visual browsers do with this information.

<oedipus> author can assist with CSS applied to image with longdesc

<dboudreau> Laura's research on londgesc is 121 printed pages long. How much stronger does our use case really needs to be?

MS: The issue is whether longdesc should be conforming. It will still work, it just won't validate.

<oedipus> dboudreau, i've been wondering that myself

<Joshue> -q

JF: The title attribute was for advisable information, but it was never specified how that should be presented to the user. The upshot was that it became a tooltip, but that was just the path chosen by the browsers. We'll have the same thing with longdesc.

<Joshue> +q to say that I don't agree with the longdesc POC approach, the requirements and use cases should be defined first and then clearly defined in the HTML5 spec. The plugins etc already exist, more of them won't help the issue.

RS: We could say that to support longdesc the UA must provide a facility to allow the user to have visual indication that longdesc is available on the element. Also that it must be a high level vehicle.

SF: I agre, but we won't get a "must" in there.
... There needs to be device independent access to the title attribute, and we've been told that can't be mandidated. We can't say that the UA is "required" to provide access to an element/attribute/information.

<oedipus> visual indicator should be an option not a requirement or default setting

JB: This isn't going to be something that gets unanimous consent. We need to articulate what we need clearly.

JF: We'll get "should", but probably not "must".

<oedipus> UA MUST provide access to and indication of LONGDESC, but a visual indicator SHOULD be an option not a requirement or default setting

JB: That may not be the case. It may need to be an override.
... I wanted to speak to the timing, which is the trickiest part of our strategy. It could play out in many different ways. We could for example have this first on the queue after the last call is issued.

RS: Would the IE team be open to the idea of a visual indicator?

<oedipus> yes, rich, but not by definitionault

CS: I'm not on the IE team, so can't speak for them, but it may be a challenge.

<Stevef> oedipus: can you point me to your long description wiki page?

<oedipus> SteveF, which the verbose descriptoin reqs or the original HTML WG page on longdesc?

EC: Same thing for Safari. The feedback from users is to put less chrome in front of us.

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

JF: There is a timeline of implementation. a plugin is the "cheap, easy and beautiful" option. If we can prove there is a need and the browser vendors can see the download data, it adds to the use case.

JB: So it wouldn't interfere with the chrome?

<oedipus> http://www.w3.org/html/wg/wiki/LongdescRetention

<Joshue> -q

RS: EC, do you have a notion of whether a plugin might e considered by Apple/Safari?

JS: Does this need to be a user action, the browser could action an auto-download.

CS: That opens up questions over security.

<Zakim> oedipus, you wanted to say as a reminder -- longdesc is a "make or break" issue for EPUB 3.0 compatibility with HTML5

<oedipus> GJR wants to address urgency of longdesc and describedby -- EPUB can't wait until Last Call, but needs a decision now to keep it aligned with the HTML5 spec as requested of the HTML WG Chairs by George Kerscher, Jim Fructerman and Geoff Freed

<oedipus> i can't hear you either -- put comments into IRC

GJR: There is some urgency on this. The important thing is that ePub badly wants longdesc in HTML5.

<oedipus> judy, yes, i'll get URI

JB: That's the same reference as in the Diagram Project letter.

DB: Usually when you can't find agreement, you need to look at it on different levels, not just technical.

JB: Yes, it is being looked at on multiple levels.

<oedipus> G Freid on behalf of DIAGRAM project to HTML WG Chairs: http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html

JB: There are various mechanisms we can look at. The requirements of last call require that things need to be fully addressed, so there is a question that the spec should go to last call now.

<oedipus> s/Fried/Freed/G

DB: I'm not sure we'll get it through using the usual channels.

JB: We do need to respond to the points that were raised, and to justify very clearly out position.

JF: It seems to me we've covered most of this withour change proposal, is there more we can add to this?

JB: Another problem I see, it isn't fully clear what the proposal on the table actually is. We're not all fully co-ordinated within the TF. The chairs would also like to see dialogue between the TF and the people who are opposed to restoring longdesc.

JF: We need to address the fact that longdesc will throw a validation error.

<oedipus> what is justification for opposing restoration of longdesc? i mean the REAL justification....

SF: That's actually a very small change.

JB: My impression is that more was needed for clarity. Does Laura's prposal include everything we need?
... The chair's impression seems to be that not everyone within the TF even agrees about restoring longdesc. Removing that confusion would give clarity.

JF: We;ve covered longdesc at previous F2F meetings.

SF: What we have unanimity on is that there needs to be a dedicated method to providing a long description.

<oedipus> HTML5 lacks a verbose descriptor mechanism (HTML bug 10052) includes requirements: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10853

JB: The technical proposal needs to be the best we can do, and this opens up other options for how its followd through.

<oedipus> requirement 1: A programmatic mechanism to reference a specific set of structured content, either internal or external to the document containing the described image

<Zakim> oedipus, you wanted to ask if describedby will be simply describedby or aria-describedby?

JF: So, what do we need to do now? We don't have longdesc in the spec, and the chairs have told us they won't discuss it until aftr last call.

JB: If the chairs did put this first in queue, feedback from the TF on what we think about that would be useful to know today.

<Zakim> oedipus, you wanted to ask if describedby will be simply describedby or aria-describedby and to ask if describedby will be simply describedby or aria-describedby in HTML5? is the

<oedipus> i'm ok with discussing later

SF: As far as ePub is concerned, what is their requirement? Do they require a specific method for providing long description?

<oedipus> SteveF, yes

<dboudreau> greg, if we removed the aria prefix, wouldn't it cause confusion? using describedby in html5 and aria-describedby in any other language?

<Joshue> A good question is to try and understand why is there the opposition to longdesc in HTML5 in the first place.

JB: Their primary concern is that longdesc is gone, after a decade or more of support.

<oedipus> SteveF, DIAGRAM/EPUB request http://lists.w3.org/Archives/Public/public-html/2011Mar/0270.html

<MikeSmith> let's take a break in 5 minutes or so

SF: So simply making it a conforming attribute would be sufficient for ePub?

<Joshue> +1 to MS

<oedipus> dboudreau, good point, but if aria is included as part of HTML, then the aria- prefix doesn't make sense

<oedipus> in the HTML context, that is

<dboudreau> joshue, there is oposition because some feel that since it's never been implemented properly by brosers and authors ailways used it wrong, it should be replaced by a better mechanism

JB: So, how can we be responsive to the concerns and to the user needs? If there is a way to evolve it to a configurable option, that would be good. If the TF could write out that path, that would also be helpful,

<oedipus> joshue, bogus web-usage statistics

<Joshue> db, yes I know that but its not a good enough reason IMO

SF: If it were brought back to conforming, there would be lots of way to look at the rest and create proofs of concept.

<oedipus> plus 1 to SF

<Joshue> oedipus, lol. He who makes the stats makes the rules..

<dboudreau> removing @longdesc based on this is pretty much like saying we should remove h1 because most authors use <p class="pageTitle">

<Joshue> +q

SF: It's the semantic indication that there is a longdesc, the mechanics are open.

<oedipus> requirement 1: A programmatic mechanism to reference a specific set of structured content, either internal or external to the document containing the described image

<oedipus> HTML5 does not provide the functions that had been provided through the HTML 4 attribute longdesc. Those functions are: 1. A direct, reusable programmatically determinable mechanism to a long description of an image without a forced visual encumbrance or default visual indicator. and 2. A method to reference a longer description of an image, without including the content in the main flow of...

<oedipus> ...a page

JB: To come back to DB's question... The fact there is long documentation isn't perhaps as relevant as *what we provide. Does it specifically defin use cases, and (as the chairs would like) does it address each point very clearly. If I can be of help in looking at the presentation of the response, I will.

JS: Are we generally agreed with this proposal, to take it as a first last call issue?

<dboudreau> +1

JS: Let me summarise... At the time they published last call, there will be a list of issues with the spec. At the top will be longdesc, and a committment from the chairs to look at this as the first priority.

JB: I think there is a misunderstanding on the chair's part that there is strong dissention within the TF about restoring longdesc. There hasn't been any of that dissention within this discussion today. Am I hearing right?

RRS: I was a dissenter, but I'm happy to go with the flow.

<oedipus> the chairs made a mistake in removing something EXPLICITLY added to HTML4 as part of the director's mandate on accessibility WITHOUT proposing an equivalent or superior mechanism, nor even the recognition that this functionality is needed

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Requirements_for_HTML5

SF: It's important that if it is restored, the spec clearly explains a mechanism for how it should be implemented that improves on the current HTML4 implementation.4

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Reinstate_longdesc_and_Add_a_Native_describedby_Attribute

<oedipus> Judy, a lot of this discussion was held up until the ARIA-in-HTML decision was issued

<oedipus> still feel strongly we need to state in this case (and in other, summary comes to mind) the chairs made a mistake in removing something EXPLICITLY added to HTML4 as part of the director's mandate on accessibility WITHOUT proposing an equivalent or superior mechanism, nor even the recognition that this functionality is needed

JS: Returning to GJR's question about what last call means... The proposal is that in May there will be a last call that includes the publication of the spec. Longdesc will not be specified in there as conforming. There will be a statement of known issues, and longdesc will beat the top and the committment is there to take that up as the first issue.

<Joshue> +1 to GJR, right on.

<oedipus> i can't speak on EPUB's behalf without pinging at least marku

JS: At the end of that process, approx. 30 days, there will be an updated last call spec that would include the disposition of that review.

<oedipus> thanks, janina

JS: I understand ePub's concerns, we're often asked to hurry alog because people need/want to use our specs.

<Joshue> -q

<dboudreau> -q

<oedipus> many thanks to leonie for minuting

<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2011-03

<Joshue> Scribe: Joshue

ARIA Lexical Processing

RS: There were couple of topics refs to role model, we have to say where role is defined.

MC: Or define it in that section, I would like role to be a global att

<oedipus> NOTE: section 3.6.2 is now section 3.6.7 http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria

RS: Ok

MC: If not we can define in the proposed section.

RS: You want to define it in just ARIA

MC: I don't think the HTML 5 wants to.

<oedipus> plus 1 to MCooper -- defined in 3.2.7 as defined in WAI-ARIA, role global attribute for HTML5 with possible exceptions

RS: Also HTML 5 has booleans, true etc. ARIA not defined that way.

<oedipus> what about the redundant stuff in ARIA that was for plugging holes that may be plugged by HTML5?

RS: A checkbox can have true,false, mixed for example, so we don't limit it in the same way as HTML5
... So we have to define the processing of ARIA?
... Mike, you wrote the section how should we proceed?

<oedipus> NOTE: section 3.6.2 is now section 3.6.7 http://dev.w3.org/html5/spec/content-models.html#annotations-for-assistive-technology-products-aria

RS: I know that DAISY eg would like to provide diff roles.

MC: Don't know what to do about that, for ARIA we want the role @ to support the various roles.

<oedipus> EPUB wants to support ARIA roles and RDFa roles

MC: We could propose the att with expanded values.

RS: Lets have a look.

MC: I suggest adding role to the list of global attr in the current HTML5 editors draft.

<oedipus> are we looking at: http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5 ??? the phone is down on your end

RS: Thats prob a good place

<Stevef> http://www.html5accessibility.com/tests/aria-changes.html

RS: What is the role attr state? CR?

MC: The HTML WG don't want to reference the ARIA role attr model

<Stevef> oedipus: have marked the chnages using ins @ del elements don't know if you can pick that up

RS: It has to be a space delimited list

MC: For sure

RS: We should take text from the role attr module and tailor it

MC: Yes

<oedipus> SteveF: now that you told me what to have my SR look for, i should be able to find them -- you might add a note to the text for others, though

<Stevef> sur

MC: We need to define all of the ARIA attr in HTML spec.

<Stevef> oedipus: will do

MC: HTML doesn't defined elements by reference..

<oedipus> http://www.w3.org/TR/role-attribute/

<oedipus> http://www.w3.org/TR/role-attribute/#s_role_module_attributes

CS: We are waiting for Ian to complete his Action item.

<oedipus> "The attribute describes the role(s) the current element plays in the context of the document. This can be used, for example, by applications and assistive technologies to determine the purpose of an element. This could allow a user to make informed decisions on which actions may be taken on an element and activate the selected action in a device independent way. It could also be used as a...

<oedipus> ...mechanism for annotating portions of a document in a domain specific way (e.g., a legal term taxonomy). Although the role attribute may be used to add semantics to an element, authors should use elements with inherent semantics, such as p, rather than layering semantics on semantically neutral elements, such as div role="paragraph"."

RS: Ian send a note about ARIA normative, I don't want to limit HTML 5 to what is in ARIA 1.0.

MC: If we can incorporate by reference thats fine.

MS: Thats what is done, MATHML eg

MC: We do need to map value types.

JOC: Not referencing a numbered version would help.

RS: Yup
... If ARIA is to define new roles, that they be limited to elements that do not restrict the roles they can be applied to.

MC: They need to be copied, I can do this via XSLT.
... We are just not using the HTML boolean type, just using them as token types.

CS: We need to be explicit about that.

MC: We want to expand that note, and make it an editors note.

RS: Start with role?

MC: Yes

<oedipus> http://www.w3.org/TR/role-attribute/#s_role_module_attributes

RS: The role attr takes this value.. lets not use a CURIE, we should take a string?

MC: I suggest a token.

<oedipus> plus 1 to token

MC: Looking at micro syntaxes, we want space seperated tokens.

RS: Yes, we do.

<oedipus> plus 1 to space separated tokens

<oedipus> http://www.w3.org/TR/role-attribute/#bib-XHTML-VOCAB

<oedipus> http://www.w3.org/1999/xhtml/vocab

RS: Are we going to sync with ARIA implementation guide? Steve?
... We will prob define mapping in ARIA 2?

CS: The guide are seperate?

RS: Yes, knew roles are features are defined, don't want to be glued to version number.
... How do we define the processing of the role values?

CS: So if ARIA has new roles?

RS: Say, EPUB and DAISY etc, re ARIA 2 we want to say the value mappings are defined in an external reference. HTML to platform A11y API Implementation Guide.
... If new roles are created

CS: In a later version of ARIA

<oedipus> http://www.w3.org/TR/role-attribute/#extending-the-collection-of-roles

RS: I want to say that those roles in ARIA are not restricted.

CS: Don't know about that, or you will only use them on <divs>

<oedipus> "It is possible to define additional role values. Such values must be defined in their own vocabulary. The URI associated with that vocabulary should resolve to a resource that allows for the machine and human discovery of the definition of the roles in the vocabulary. One format that achieves this is the RDFa Profile as defined in [RDFA-CORE]. Note: If this attribute is used in conjunction...

<oedipus> ...with RDFa (see Appendix A), then the vocabulary definition must be the same as that required by RDFa."

CS: We don't want to say that only certain elements etc would accept ARIA roles etc
... I want to say that there is some restriction to new ARIA roles.

SF: This refers to strong native semantics and implied semantics..

MC: We have three external and two internal refs..

<oedipus> do we want to align role extention with RDFa-Core? http://www.w3.org/TR/2010/WD-rdfa-core-20101026/

RS: So if we define new ARIA roles we have to update the implementation guide?

MC: Yes

RS: Perfect.

CS: But no that duplicates the funcionality of the implementation guide?

RS: We just need to point to mapping for any new ARIA updates.

MC: Yes, the WAI-ARIA User Agent Imp Guide..

CS: Yes, we can edit that at will.

RS: So there won't be a ref to implementation guide?
... Will will need normative references to the UA guide?

MC: Yes, we have that now.

CS: So how about something that states new ARIA roles cannot be applied to elements that do not allow override?

<oedipus> using role in conjunction with RDFa http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-rdfa

RSSAGENT, make minutes

<oedipus> "If a Host Language contains the @role attribute, then an RDFa processor processing a document written in that Host Language according to the rules of that Host Language may generate additional triples for role attributes. If these additional triples are being generated, then they must be generated as follows:"

CS: We don't want to be too restrictive..

RS: There may be a fight.
... Ian asked about what is normative, I think we have to do this.

CS: If we make an ARIA overide at some stage, we need to be able to add that.

MC: Getting the group to agree to externalise this section would be good.

CS: I agree.

SF: We want Steves annoteted doc externalised

<oedipus> cooper, by externalize, do you mean split off into a separate document, like the Alt Techs doc?

s/annoteted/annotated

<oedipus> won't we be accused of cyber-ghettoization?

SF: Ian did say that role="presentation" can be on anything.

RS: Yes
... Two things, we need to say what happens when ARIA introduces new roles.
... Also what happens when a role value is provided if not listed in HTML5 spec

<oedipus> on ANY element? <head role="presentation" > doesn't make any sense... is there an exception for elements that appear in the HEAD

MC: They might want a conformance warning..

CS: Yes

MS: Currently I don't think the spec does define this.
... It does say role attr * etc can be used

<oedipus> spec should at least limit role="preentation" to elements that occur in the BODY of a document

<oedipus> er, role="presentation"

MS: I don't see a restriction on what can be implemented in validator.

MC: ARIA 1.0 does say take the first recognised token..
... Then ARIA spec say all it needs to.

RS: So are we ok with ARIA role def?

<oedipus> what is the ARIA role def -- as tweaked today?

MC: If we externalise this stuff we can fix more easily

RS: If we wish to add new role values, etc we wish to state it would not create a conformance error?

MC: Don't really mind, to have warnings may not be ideal.

<oedipus> RS, as long as the role value is documented as per Role Attribute verbiage

<oedipus> "Note If this attribute is used in conjunction with RDFa (see Appendix A), then the vocabulary definition must be the same as that required by RDFa." http://www.w3.org/TR/role-attribute/#using-role-in-conjunction-with-rdfa

s/implemtation/implementation

MC: This is kinda like microformats, we need an interoperable web..

RS: Regarding DAISY etc, they may ignore these warnings.

CS: They should come up with there own schema

<oedipus> EPUB wants to ensure that it is as close to HTML5 as possible so as to allow rendering of EPUB content in HTML5-capable UA

MS: In HTML 5 we have no normative schema.

<oedipus> cyns, EPUB will come up with own, if can't get from HTML5 -- point is, they'd rather not have to come up with their own, but reuse native semantics

MS: The EPUB group were concered about developing their own schema.

MC: The values that are allowed changes by element.

RS: Is the title going to remain?

The 'Annotations for Assitive Technology' doc

<oedipus> break now for lunch or are we continuing through lunch?

<oedipus> s/break now for lunch or are we continuing through lunch?//

<oedipus> can i step away for a break or are we coninuing? if a break, how long?

<oedipus> er, continuing

<oedipus> dboudreau, the reason we didn't make describedby capable of taking an external URI was: 1) we thought that LONGDESC already did that and liked the solutions offered by SVG (namely, a container into which structured content could be put) and 2) when it did come up as a potential replacement for LONGDESC, ARIA was already finishing its second last call period, and making the change to...

<oedipus> ...describedby would have necessitated a return to Last Call, when we REALLY want to get ARIA through CR!

<oedipus> s/already finishing/already in/

<oedipus> HTML5 Section 7.2 - "Activation" http://dev.w3.org/html5/spec/editing.html#activation

<oedipus> HTML5 Section 7.3 - "Focus" http://dev.w3.org/html5/spec/editing.html#focus

CANVAS

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas

SF: Regarding the mapping doc is there a prefered place for that?

MS: In the ARIA section.

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals

MC: I should do a CP
... I would like to take over the doc that Steve has been editing.
... I will then do a proposal with suggested additions etc

<Stevef> http://www.html5accessibility.com/tests/aria-changes.html

RS: Are we doing to have a what ARIA dot (incremental) version?

<oedipus> Stevef, do you have any comments on HTML WG Bug 10905 - clarify how assigning an accesskey to an element affects the elements default role filed by Steve Faulkner http://www.w3.org/Bugs/Public/show_bug.cgi?id=10905 for http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs#Bugs_marked_RESOLVED_WONTFIX

MC: We haven't decided yet

<Stevef> oedipus: will look

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals

RS: Re: canvas, we have a CP out now. We'll talk about hit testing for a11y APIs.
... It would be great to have someone from Apple to float some concepts about clickable regions.

<oedipus> scribe: Gregory_Rosmaita

<oedipus> scribenick: oedipus

MC: agenda has media people in breakout for most of 2 days
... could see if GJR ready for Access discussion

http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

most of them have status reports

RS: returning to CANVAS
... problem: for a11y and authors -- very difficult to do clickable areas for authors (hit testing)
... want to introduce concept of clickable region as have in windowing system -- dates back to windows 3 -- when draw to desktop, have device context (font, color, clipping region, bounding rectangle)
... when click on screen app in windows calls into app (hit test) -- if child in there, keep going through -- know clicked in area -- not a concept contained currently in CANVAS
... what you can do is...
... fills rest of gap we have

RS: <adjusts screen resolution>
... function call -- find clipping region
... then say setClickable Region and set that in canvas subtree -- when click in clicakble region, you would operate off DOM to get coordinates and bounding box

<Joshue> CS: Microsoft did a demo of <canvas> a11y yesterday in IE9

SF: focus management question -- want checkbox kbd accessible

RS: is kbd accessible
... now can have clicks and kbd support -- nice and clean

SF: getting method for using canvas subDOM different from dev to dev

RS: talked about CSS -- problem is transformations that canvas does -- don't have to do that with proposal
... worked with Charles Pritchard on this -- problem clickable region support
... whatever UA does...

RS: does all transformations without additional overhead
... do people like this approach?

RS: so can i advance this?

<yes>

<Joshue> +1 to Richs idea

plus 1 to advancing RS' idea

RS: problem with CSS is transformations issue
... limited by tools at disposal
... hit testing a trip down memory lane...
... can do before LC? re-definig clickable regions -- bigger than a1yy

s/a1yy/a11y/

s/re-definig/re-defining/

the only one i can't hear is MikeSmith

now i can't hear anyone but Cyns

RS: click goes to first thing, then bubbles up
... what you click on has to start at some element, probably lowest level of DOM
... if MikeSmith could write up what he just said, that would be great

CS: remember computation on that level -- don't want to increase burdens

<MikeSmith> http://dev.w3.org/html5/spec/infrastructure.html#event-click

<MikeSmith> http://dev.w3.org/html5/spec/references.html#refsDOMEVENTS

<MikeSmith> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

Activation in HTML5: http://dev.w3.org/html5/spec/editing.html#activation

focus in HTML5: http://dev.w3.org/html5/spec/editing.html#focus

MS: what happens if have touch device?
... actuation method of DOM (couldn't hear)
... <reads from something>

RS: have to say bounds of element are defined by <unintelligible>
... if setClickable region, bind to that element, that section is defined based on what is associated with that element in the DOM

<MikeSmith> ok

RS: this is region associated with that handler
... if click in any of those areas, possible to hit test to get bounds
... if we could get text for the spec, that would be good

MS: event is fired as whatever elment clicked on

RS: determines what click on

MS: what is method to capture event?

CS: if put in method to get caret <couldn't hear>
... if event listener catches event, does the job

RS: UA directs mouse to child --

RS: i'm going to associate clipping region i have to define how that object associated with that clipping area is determined <couldn't hear>

CS: whatever you bind to -- even a parent that gets clipped -- still works

RS: problem is on normal web page -- you clip, you know the DOM target, but on CANVAS, need to find a way to map that area to that object and properties
... layout engine does this anyway, but doesn't specify how to determine <couldn't hear>
... are TF members ok with this approach?

<can't hear>

RS: even though specify rectangle, canvas doesn't take rectagle -- can use an ellipse or other more complicated shapes
... setClickable.Region to passive

<can't hear due to white noise>

CS: if do for anything other than rectangle what will happen?

RS: can be triangle

CS: need to define shape first?

RS: a11y api purposes, use rectangle or triangle

CS: if tab, going to get focus rectangle

RS: focus.screen can be circle, ellipse

CS: if use recatagnle to bind event handlers, how would that impact <couldn't hear>

RS: this is canvas, not "straight HTML"

<Joshue> s/ recatagnle/rectangle

RS: specify this using wording
... have to have function that says, based on viewer and DOM tree that that position is in that clicable region
... pick lowest point of DOM tree that has highest lean-over

CS: how do you fix?

RS: have to have different rule for defining other than rectangle

CS: worry is getting it implemented

RS: clean way to do hit testing
... bind canvas to object use what have in HTML to bind object fallback content with drawing path exposed via canvas --
... cleanest way to support a11y API because don't have to do transformations in CSS to reproduce transformations in canvas

CS: understand RS point
... want it documented

RS: nothing new -- this is a "rich drawing space"

CS: can be different shapes

RS: yes -- requires author-end work

<can't hear very clearly>

<can't hear discussion>

<er, squiggly>

<richardschwerdtfe> can you hear me?

yes

<cyns> I said that moving from the html rectangle-only hit testing in browsers now to arbitrary paths may be a lot of implemenation work

RS: diff between hit testing in canvas and on HTML is largely like desktop -- do hit testing within rectangles, so is trivial thing to say whether this piont is in bounds of rectangle
... however, can have squiggly path that is closed, but not uniform in terms of trectangle -- finding out if click in path is more challanging -- is that going to be a problem for UA devs
... currently all of that is handled by canvas author
... when looked at DOM event spec did not define how it knew when position within bounds of the element that you were trying to click on
... can have things like an option in listbox -- how do you know you are within option in list box -- send to listbox or listbox container
... cleaner, but redefines what is not clearly defined in DOM Events spec for how do DOM hit test
... no other way to do this right now --
... whatever shape provided, have to do "best fit" rectangle for the a11y object because only use rectangles in a11y API

CS: sounds like could be a lot of extensive implementation work -- poetentially destablizing -- expect vendors to be wary of that

RS: bring this back to discuss with Frank Oliver

MichaelC, are you luring FrankO to RichS with chocolates?

<richardschwerdtfe> :-)

CS: what happens when canvas area is non-rectangular?

<can't hear FrankO>

CS: put click handler on canvas DOM

MichaelC, should this be minuted -- can't hear -- 2 discussions at once

RS: have method in canvas for pointing to path -- work for key order?

MC: plenary stuff for afternoon
... look-up table auto-generated for aria state and property looks up HTML ValueType

RS: if we define new property?

MC: regenerate it
... why want to externalize section of spec, so can update it indepently

MS: people can disagree, but don't think it is a non-starter

CS: initial resistence, perhaps

RS: don't want to waste cycles spinning own wheels

MC: need lookup table like this
... demand for it

RS: why not keyword enumerated values as defined by Blah
... i can have aria values defined as this this and this -- keyword enumerated values -- what aria defines in spec today
... if have space delimited token list, have another one
... IDREFs another type

MC: that is data lookup table would provide
... do you want into organized by HTML type and aria attributes that apply?

RS: want to avoid having another document
... in aria subsectino define diff types -- for types, here how to process
... whitespace
... how to deal with whitespace

MC: doesn't use that term any more

RS: for IDREF, what would you call it?

MC: defined in mapping table
... IDREF is the value of a defined id value on another element -- most precise concept can find in HTML5

RS: so refer to IDREF, point to that
... don't have to id all individual attributes -- all the attributes refered to in ARIA section...

section 3.6.7 in current editors' draft

RS: IDREF defined in this section of the aria spec is processed as follows

MC: what have now
... defines what to do in HTML

RS: ok, but didn't like, because?

MC: if user agent implementor and implement ARIA state and property attributes -- hear values -- don't want substitutions or stopping because doesn't know what to do, so would have the link that takes you to the table that is intended to be generated

RS: why not just put that table in the HTML5 sperc

MC: intend to
... can do that -- don't know if would satisfy,
... want to hear what HSivonen has to say about it --

RS: where do we have true/false enumerated values
... refer to true/false in table -- in atomic data type?

MC: <shows RS table (i think)>

RS: perfect!
... these are the diff types as defined in aria, this is how processed in HTML, and put the table in it
... put in Annotations for Assistive Technologies (ARIA) section

MC: or make informative external reference

RS: has to be processable

MC: everything specified -- do you know where to look for it
... do need to know spec well enough to follow a link

RS: put somewhere in this section "WAI_ARIA is a cross-cutting technology. Therefore, the actual implementation of aria must be specified for each host language. For HTML here is the implementation:"
... don't want to have to have any change to ARIA contingent upon any other group's processes
... who has change for this section?

MC: definition for role attribute

RS: primary change proposal

potential ACTION for Cooper - take SteveF's Lexical Processing prose, add definition of @role, and propose as change proposal

<scribe> ACTION: Cooper - take SteveF's Lexical Processing prose, add definition of @role, and propose as change proposal [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action02]

<trackbot> Created ACTION-112 - - take SteveF's Lexical Processing prose, add definition of @role, and propose as change proposal [on Michael Cooper - due 2011-03-26].

RS: want to get feedback on default roles for elements in HTML5 -- do we need? should we do a longdesc -- remotedesc?
... want to know what to plan for ARIA.next
... like to start circulating a list; would be fine if response is "we don't need anything"

MC: media group wants to continue current work

http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

MC: timeline review and writing change proposal -- how much time?

MS: walk through of chairs' decision policy

MC: should open to everyone

<Stevef> as per earlier discussion http://www.html5accessibility.com/tests/img-longdesc.html

SF: marked up some spec text for review

MC: preliminary review as sub-group

Longdesc Redux

<richardschwerdtfe> scribe: Rich

<richardschwerdtfe> Subject: Longdesc

<scribe> scribenick: richardschwerdtfe

Steve: we need to be conformant
... we need to be normative

<oedipus> http://www.html5accessibility.com/tests/img-longdesc.html

Steve: As I said there are minor edits.

The text:

The longdesc attribute may be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a separate document, a content fragment in a separate document or content fragment within the same document as the image.

Content referenced by the longdesc attribute, if present, must be exposed by the user agent via a device independent mechanism.The user must be allowed to make a decision on whether to access the content referenced by the longdesc.

For example, a user agent may provide access to the document or document fragment referenced by the longdesc attribute in a context menu associated with the image. In this case the context menu must be operable using the keyboard and a visible indication of longdesc presence must be provided. The option to disable visible indication and access may be provided via a user preference.

Cynthia: this is too strong

Steve: it is a starting point

More text:

Another example is to provide an indication of the presence of a description via a programmatically associated visible button or link. The button associated with the image must be included in the default tab order of the document. The button may be hidden until an image is moused over or receives keyboard focus, then user agents must provide a visual indication and mechanism to access the associated description. Clicking on the button or pressing a

when the button has focus will navigate to the referenced content or provide an inline display of the referenced content. Visible indication and access may be user configurable.

Steve: I provided an inline example using IFrame

Cynthia: I would like to say that the visual indications are MAYs or SHOULDs
... What is actually required is the way an AT can access it.

John: What we have is ...

Cynthia: I am not convinced that the case for making longdesc visible is strong enough

Mike: I think it is important that we get it available to the rest of the working group. Making it discoverable is useful. It is useful to have these examples.

<Stevef> http://www.html5accessibility.com/tests/img-longdesc.html

Cynthia: all the examples of visual renderings need to be SHOULDs and NOT MUSTs

Leonie: Why is it a must for one group of disabilities but not another

Cynthia: I am not convinced that the example is a strong use case

Steve: Having the provision of content in text form is good for some users.

John: we do not have data.
... The WhatWg has stated that not having a visual indicator is a problem

<Zakim> oedipus, you wanted to say that longdesc simulteneous display for cognative guidance and limited viewport guidance through image / assistance in interpreting image

oedipus: Did you not find users with a very limited viewport a valid viewport?

Cynthia: I believed that was hypothetical

<oedipus> no, not hypothetical -- we have extensively courted feedback on that

Steve: users don't know it would be possible

<oedipus> especiaally in the case of graphs and charts

Roger: It is a valid use case for low vision users who can't see the whole graph to be exposed to the text

Steve: I put MUSTs in the chart so that we can roll backward. Don't be overly concerned about that. If the sort of features that we are talking about here the way we want to go.
... Should we expose URL through the description field in the accessibility API

correction: Cynthia said that

Steve: The NVDA guys said we should not have to expose this. It should be exposed via the browser.

<oedipus> i agree with NVDA dudes -- it SHOULD be exposed by the browser, but (in the words of WCAG 1.0) "until User Agents support..."

Rich: I am not a big longdesc fan, but my concern is that users with cognitive impairments will need to see the longdesc text.

Cynthia: not many sites use longdesc

John: ... create more longdescs

<oedipus> cyns, it depends upon your definition of the term "use"

Cynthia: My point is that script can be used by the author to expose the longdesc

<oedipus> longdesc is there, some mandate it, all want to use it, so let's get off the fence and support it

Cynthia: this might be better if the author does it

John: I said earlier that I don't think MUST is going to fly but I would like to see a SHOULD or SHOULD+
... but if this is the problem here is how to fix the problem

<oedipus> easiest fix is to "restore" longdesc -- it doesn't take any work --unlike removing it

John: the argument we are getting is that there needs to be a way of describing longdesc info to sigted users

Content referenced by the longdesc attribute, if present, should be exposed by the user agent via a device independent mechanism.The user should be allowed to make a decision on whether to access the content referenced by the longdesc.

For example, a user agent may provide access to the document or document fragment referenced by the longdesc attribute in a context menu associated with the image. In this case the context menu should be operable using the keyboard and a visible indication of longdesc presence should be provided. The option to disable visible indication and access may be provided via a user preference.

<oedipus> from what i hear, it sounds as if it conforms to the verbose desc reqs! <wink>

Another example is to provide an indication of the presence of a description via a programmatically associated visible button or link. The button associated with the image must be included in the default tab order of the document when present. The button may be hidden until an image is moused over or receives keyboard focus, then user agents should provide a visual indication and mechanism to access the associated description. Clicking on the button

pressing a key when the button has focus will navigate to the referenced content or provide an inline display of the referenced content. Visible indication and access may be user configurable.

<oedipus> if a user agent is set to receive keyboard focus for @longdesc, then it MUST add the element for which the @longdesc was defined to the document's tab navigation order

Steve: where should that go?

<oedipus> it can go at the end, can't it?

<oedipus> thanks steve

<cyns> Another example is to provide an indication of the presence of a description via a programmatically associated visible button or link. <ins> when present</ins> The button associated with the image must be included in the default tab order of the document when present.

<cyns> Another example is for the browser to add the longdesc to the accessibiity API such that AT can access it and expose it to users.

<oedipus> need to cover those using AT and those not using AT but for whom the longdesc would be beneficial

Steve: mouse over may provide a button to click
... I don't have a problem providing an example of how it should work

Cynthia: I am fine with that but specifying the UI is not our job

MIke: what's next?

Rich: Do you want to put a change proposal in?
... Start writing a change proposal for it

Cynthia: Put this stuff in the change proposal

Steve: I said to Laura we needed a more robust mechanism for this

<oedipus> discoverable versus hidden metadata

<Stevef> oedipus: no problem

<scribe> ACTION: Steve create a change proposal for longdesc that includes example of how a user agent might render longdesc information [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action03]

<trackbot> Created ACTION-113 - Create a change proposal for longdesc that includes example of how a user agent might render longdesc information [on Steve Faulkner - due 2011-03-26].

<oedipus> rich's wording sounds to me as if it would be more palatable to the HTML WG

<MikeSmith> http://dev.w3.org/html5/status/issue-status.html

Open Issues

<scribe> scribe: Leonie

<lwatson> scribe, lwatson

<oedipus> scribenick: lwatson

<MikeSmith> regarding issue 31, http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElementSurveyConformaceChoices gives a really good overview of the differences among the various change proposals

<MichaelC> ACTION: Cynthia to work with Steve and go through decisions from Lyon and document them regarding HTML-ISSUE-31 [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action04]

<trackbot> Created ACTION-114 - Work with Steve and go through decisions from Lyon and document them regarding HTML-ISSUE-31 [on Cynthia Shelly - due 2011-03-26].

MC: Issue 32, table summary.

CS: Did that get escalated?

MC: It's in the hands of the chairs, so I think there's othing for us to do now.
... Issue 80, title alternative. In chair's hands.

SF: It's been with them for ages hasn't it?

MC: Issue 92, clean up table.

<oedipus> http://www.w3.org/html/wg/wiki/ChangeProposals/summary_element

MS: Done.

<oedipus> i have action to comment on poll for ISSUE 122

<MikeSmith> http://dev.w3.org/html5/status/issue-status.html

<oedipus> on behalf of HTML A11y TF

MC: Issue 131, canvas text.

MS: Deadline is 22nd to modify the hange proposal.

s/hange/change/

MS: One thing we should discuss is whether we're happy with this change proposal.

MC: Was this subitted in a hurry?

RS: We have the bounding rectangle, but it doesn't necessarrily apply to this.
... We took out references to rich text, so we're not saying "go do rich text".

MS: If there are no cunter proposals, we need to adopt this.

MC: Issue 133, modal dialogues.
... Do we want this and do we like what's here?

<oedipus> i am proposing the modal dialog for ARIA.next

RS: What we need is a dialogue element that specifies modal.

<oedipus> s/dialogues/dialogs/

MC: Is there anything besides a dialogue that could be modal?

SF: Yes.

RS: I would like to have the use cases enumerated here.

SF: You can have fall back as well. If your JS isn't working for example.

CS: This is a post last call issue.

<MichaelC> ACTION: Schwerdtfeger to review ISSUE-133 and consider whether a refined (counter) proposal needs to be submitted [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action05]

<trackbot> Created ACTION-115 - Review ISSUE-133 and consider whether a refined (counter) proposal needs to be submitted [on Richard Schwerdtfeger - due 2011-03-26].

MC: Issue 124, tab states.

s/124/134/

<oedipus> might be affected by ARIA-in-HTML decision

<oedipus> cooper is correct

MC: this is creating native attribs that are like ARIA attribs.

RS: I don't like tabbing through a tab panel, or tabbing through a menu.

MC: This is attempting to allow menus to be defined as tablists.

<oedipus> borrowing concepts from ARIA for HTML5 -- might be OBE by ARIA-in-HTML decision

MC: So we support the change proposal.

RS: Give me an action to review this one.

SF: If something has a modal attrib, it's default role could be dialogue.

<oedipus> s/default role could be dialogue./default role could be dialog/

SF: We should have a discussion as to whether it should be an element or an attribute.

<MichaelC> ACTION: schwerdtfeger to review ISSUE-134 [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action06]

<trackbot> Created ACTION-116 - Review ISSUE-134 [on Richard Schwerdtfeger - due 2011-03-26].

MC: MC: Issue 135, link canvas spec.
... Looks like there has been a call for consensus amongst the chairs on this.
... Issue 142, poster alt.

JF: The poll closed, and we have two change proposals.
... It's waiting for the chairs.

<oedipus> http://www.w3.org/2002/09/wbs/40318/issue-142-objection-poll/results

MC: Issue 144, underlining <u>

CS: No harm to make it conforming.

<oedipus> presentational elements should be only conforming with a warning -- USE CSS!!!

s/underlining/conforming/

MC: Issue 147, playback rate undefined.

JF: Doesn't affect us much.

MS: We should get Sylvia's input on this.

MC: Issue 153, link external.
... Issue 155, cell border.

MS: I've read through this but not sure I fully understand it.

CS: Don't think it's an accessibility issue.

MC: Issue 161, accessibility API mapping.

CS: We need to do some work there.

SF: It's just to add a link in there.

MC: Issue 163, navigating tracks

JF: We're discussing this tomorrow.

MC: The bug triage sub team hasn't seen any bugs it needs to take a look at.

<oedipus> i am in contact with others in w3c about bugzilla 4.0 a11y improvements and those that still need to be logged on bugzilla's bugzilla

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

MC: There are five bugs...
... 10249, canvas requires a content selection method, assigned to RS.
... It needs expanding, or closed.

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10249

<oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10896

MC: 10896, enable device independent access to event handlers, filed by LW.

<oedipus> hixie said that he thought it more appropriate for the DOM / WebApps / WebEvents group for DI access to event handlers

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/event_handler_requirements

MC: 11328, canvas authors need to be able to assess pixel resolution, filed by RS.

CS: Assign it to Doug, he should be able to find someone to look at it.

MC: 11329, HTML5 supporting browsers must support resize event during zoom, filed by RS.
... It's been assigned to Web Apps WG, is that the right place?

JF: Is this a TF concern?

CS: Yes, it relates to zoom.

MC: 11391, provide examples of track usage, filed by FO.

MS: This would make the track element usable for additional audio tracks.

JF: So this is related back to issue 152.
... Think I may have reported this back to Martin a couple of weeks ago.
... Think I may have reported this back to Martin a couple of weeks ago.?

MC: So here's nothing else to do on this right now?

<oedipus> we could look at http://www.w3.org/WAI/PF/HTML/wiki/Access/HTML5_Accesskey_Bugs

<MichaelC> ACTION: foliot to raise Bug 11391 with media sub-team [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action07]

<trackbot> Created ACTION-117 - Raise Bug 11391 with media sub-team [on John Foliot - due 2011-03-26].

MC: We needed to do a review of the whole spec, but this could be a PF action as opposed to a TF action.
... The idea was to start writing WCAG techniques as a mechanism for discovery.
... Nothing for us to do on spec review right now.

MS: It looks as though we don't have any outstanding actions on drag/drop anymore.

SF: Gez and Everett looked at the spec and seemed not to have furter concerns.

RS: What happens if ARIA is used with respect to HTML5 drag/drop? Could we ask Gez to look into this?

<MichaelC> ACTION: Lemon to review if HTML drag and drop model conflicts with ARIA drag and drop model [recorded in http://www.w3.org/2011/03/19-html-a11y-minutes.html#action08]

<trackbot> Created ACTION-118 - Review if HTML drag and drop model conflicts with ARIA drag and drop model [on Gez Lemon - due 2011-03-27].

<oedipus> [ADJOURNED]

MS: Meeting adjourned.

- DRAFT -

HTML Accessibility Task Force Teleconference

19 Mar 2011

Attendees

Contents

Text alternatives

Longdesc

ARIA Lexical Processing

CANVAS

Longdesc Redux

Open Issues

Summary of Action Items

Scribe.perl diagnostic output