HTML Accessibility Task Force Face to Face, Day 1

06 Apr 2010


See also: IRC log


Gregory_Rosmaita, Sally_Cain, Marco_Ranon, Eric_Carlson, Rich_Schwerdtfeger, Janina_Sajka, Joshue_O'Connor, Michael_Cooper, Mike_Smith, Charles_McCathieNevile, Steve_Faulkner, Cynthia_Shelly, Martin_Kliehm, Sean_Hayes, Laura, FtF
richardschwerdtfe, Joshue, Sally, MichaelC, MikeSmith


<trackbot> Date: 06 April 2010

<janina> Hi, Everyone! We're starting momentarilly. It'll be a moment or two while we find scribes for the morning.

<janina> We're sending pastries your way -- e-pastries, that is ---

<janina> We have two, count 'em, two Ipads in the room here.

<janina> We're on the Zakim bridge, now. Please join.

<silvia> I will only call in when absolutely necessary, since I am actually staying at friends this week

<silvia> I am following irc though

<janina> OK, Sylvia. BTW: We'll discuss moving the Media discussion to an earlier hour tomorrow in a moment.

<silvia> that is very much appreciated, thanks

<janina> No Skype, I'm afraid.

<richardschwerdtfe> scribe: richardschwerdtfe

Janina: we should expect Steve Faulkner and Martin Kline around 10am
... lets get something easy to do by 10


Janina: we have spent a fair amount of time on a couple of topics we need to cover
... we have some things near completion

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

Janina: The hope in this meeting is that we are closer to consensus on a number of these issues

<oedipus> http://www.w3.org/html/wg/tracker/issues/30

janina: we need to collect recommendations and send to the group at large for later submittal to the main HTML working group

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

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

janina: we will meet with the main task force a week from this Thursday

chaals: when are we doing the video discussion

janina: sometime early tomorrow so that Sylvia may be available at a more reasonable hour

<silvia> thanks

janina: we are fairly close to consensus on a number of issues
... we can start 9am tomorrow morning on media

<silvia> excellent, thanks

<silvia> should Dick be delayed, we can do it a bit later, too

<oedipus> congrats, rich

<oedipus> http://www.w3.org/html/wg/tracker/issues/30

janina: what to say about longdesc

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

janina: you have a change proposal in

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

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

<oedipus> first wiki page is chaals' change proposal

janina: short and long descriptions related to aria-describedby

chaals: The change proposal is pretty straight foward. longdesc is not clever and is not all that bad and when it is there it serves its purpose. So, I don't see why we should throw it away.

<oedipus> longdesc would have been more widely implemented if had been DESCREF (that could be an external HREF or a bit to be embedded in document containing image

chaals: we spent a trivial amount of time implementing it
... aria-describedby only provides an in-page reference
... I don't plan on taking longdesc forward
... the value of the out of page reference is important for content management systems
... google would not trust this and would treat this as a spam vector
... the long and short is this is simple stuff and works in a tiny minority of cases

<oedipus> Opera longdesc extention: http://userjs.org/scripts/browser/enhancements/frameset-links

<oedipus> mozilla longdesc add-on: https://addons.mozilla.org/en-US/firefox/addon/273

chaals: the implementation of longdesc has been woeful

<chaals> [Opera implemented longdesc support natively in 10.10 last year]

janina: one point and the ability to ...

<Zakim> oedipus, you wanted to say that aria-describedby isn't a solution to longdesc, but a technique that relies on ARIA support

<Joshue> +q

janina: you could have aria-describedby to point to a link

rich: yes

chaals: but it is not a direct link

gregory: aria-describedby is not a replacement for longdesc but a technique for identifying detailed descriptive text

janina: I think the use case is easy. We need it
... education is a good example for why we would need longdesc
... but what is the mechanism for getting at it.

<oedipus> solution should be NATIVE not an overlay

janina: I am concerned that we are going to have two mechanisms to get at long descriptions. ... I am concerned about bloat

josh: I guess one of the things I am concerned about is that longdesc is well defined
... I think we should look at why it failed. ... why has there been little use
... we should look at why it does not work
... longdesc can take a URI that the screen reader could buffer and we would need AT vendor buy in
... longdesc wins for me
... why has it not really worked?

<Zakim> chaals, you wanted to say it isn't the mechanism for getting to the description that matters, but getting it written and used. IMHO

chaals: there are two things at stake. One is getting decent descriptions
... that has not happened
... why did it fail. We spent more time in Opera arguing why we should use it

<oedipus> implementation in AT is spotty too -- JAWS spawns a new browser instance to display LONGDESC on user request and no other way to have exposed by JAWS

chaals: In a
... in ARIA 2.0 we could have aria-describedby support an off page and on page representation
... the idea of having a prefetch is a problem
... the likely thing is that longdesc is here we should use it now and it will be deprecated later.

<Zakim> oedipus, you wanted to say for such a basic feature the solution should be native to HTML5

oedipus: for such a basic feature it should be part of HTML 5

<Joshue> +1 to GJR, the same could be said for most accessibility related stuff.

oedipus: if we push it off to aria alone we will cut off a lot of users will benefit from it

<oedipus> strong plus 1 to MichaelC

michaelC: aria is meant as a technology that will be subsumed over time

<SCain> +1 to using longdesc rather than aria-described by for now

michaelC: the reason ARIA is needed as the language does not support a set of features

<oedipus> 2007 PF expresses preference for native solutions in HTML5: http://bit.ly/8Yr31k

janina: the answer sounds like this - yes there is some overlap but the overlap fills a function
... the new direction (aria) requires a two step process

<oedipus> also problem of aria-describedby being used as a 2010 D-Link

mikesmith: we will get pushback
... people will argue that people do not use it properly now
... josh's point is very relevant

<oedipus> longdesc was good enough for CSS2 - there are over 45 longdescs in that TR

chaals: we know authors do not use it properly. ... my point is who cares?

<MikeSmith> ?

<oedipus> implementors can think of longdesc as DESCREF (embed or external)

<Joshue> +q

chaals: there is a measurable amount of content where peope do use it correctly
... the fact that people like Freedom Scientific use it because there is a demand for it

janina: we should at least honor the need to trim off the dead branches

<oedipus> LONGDESC may be a shakey branch, but not a dead one

<chaals> [/me is not going to drop on a sword. We will just keep implementing it anyway]

janina: you would get google caching your results

<oedipus> LONGDESC been used in W3C TRs (CSS2, RWAB XG final report, etc.)

<chaals> scribenick: chaals

Rich: Having implemented longdesc, 2 things bother me. 1 - create and maintain a separate page, 2 - there is a context switch required for the user.
... So what would HTML accept? If we had describedBy takes a URI would they accept that?

SteveF: They don't like it in general.

<oedipus> if LONGDESC was DESCREF

<oedipus> the same thing as longdesc - it is just a term

GJR: Doesn't matter if the URI is external or embedded

<cyns> my mike's not working

<cyns> it's cynthia

<oedipus> was that denis?

<cyns> lol

<oedipus> i have a proposed "solomonic solution" in my queued question

<Zakim> MichaelC, you wanted to ask if lack of support for longdesc in HTML is because implementation of "longdesc" isn't well done, or implementation of "long descriptions" isn't done

RS: We need long descriptions - one way or another.

<oedipus> In situations where images are not available to the user (because of disability, choice, or UA limitation) there is a need for a mechanism that presents equivalent content to the user, either as an alternative to the image or in a side-by-side exposition.

<oedipus> Equivalent content is not, nor should it be, and either/or proposition, and its method of exposition should be subject to user control, as some user groups may need both the image and its detailed description in order to make sense of the image or — in the case of a user with an extremely small viewport — to follow the image's flow.

RS: putting alt text isn't good enough. I put a long description and point to it. All the time.

<oedipus> amen, chaals

RS: as we get more dynamic content and more graphics we will need longer descriptions. Whether they go on a different page is an implemnentation detail.
... we have been doing this internally for meetings and there are lots of details to sort out about how these get shown (or not).
... is there a way we can do this without requiring the use of another page?

JOC: If longdesc allowed inline content would that work for you?

RS: Yes. Having fallback content for images is interesting...

<richardschwerdtfe> scribe: richardschwerdtfe

josh: longdesc was poorly implemented by authors
... this will always be a niche thing for people
... It is up to me for what I do

chaals: we could have fallback content and it has been implemented for a decade. The likely uptake for this is to have an element with fallback content
... this won't work for image
... architecturally allows us to have in page or out of page content
... the implementation to support in context is a trivial piece of work for a user

<Joshue> +1 to Chaals (and now I remember my second point)

chaals: the objection by the html working group that this will have crap content is really a "so what" response.

<SCain> It is about having the choice to read longdesc if you need/want it

chaals: there are fundamental problems with invisible metadata
... people are going to do a crap job because they don't care
... noone has demonstrated that you will break the web

<oedipus> the tree has to be in the forest if anyone is going to hear it fall

chaals: Google only searches a fraction of the web
... people do search the web because it is of valuable to them

<MichaelC> +1 that philosophically avoiding invisible metadata vs providing info needed by some people (but others don't want to have to see) is a problem

chaals: what makes people think that aria-describedby will be any different

<oedipus> it is NOT "invisible metadata" BUT "discoverable metadata"

chaals: this is not something we should die on this hill for

<Joshue> +q, to ask can we discuss this issue of invisible metadata (briefly)?

chaals: If they don't support it in HTML 5 I will instruct people to do it
... there is nothing that fulfuills this functionality

<Joshue> +q or discoverable metadata

<Joshue> +q, or discoverable metadata even

<Zakim> oedipus, you wanted to say that LONGDESC could be like my proposed SUMMARY element -- a child of IMG and FIGURE which is NOT rendered by default, but can be rendered in a multiple

chaals: the argument that the web is not pure - which is true. But having something in a spec that is interoperable and we can recommend will allow us to produce more improvement than saying "well, you should do something but we don't know what". And if we don't figure out how to make longdesc work, it is unclear how we might make aria-describedBy work anyway

<Joshue> +1 to GJR

gregory: it is discoverable metadata

steve: I spend all my work time trying to advise companies on how to make content accessible

<Joshue> +q to ask about this issue of discoverable vs invisible metadata

steve: I would not recommend that they use longdesc
... it is only supported by 2 of the main screen readers
... I don't think it should go away
... i just would not recommend it
... the assumption is that aria-describedby does not support rich content

<Joshue> scribe: Joshue

RS: It doesn't restrict rich content
... The problem is that the IE implementation is incomplete

<oedipus> rich, are you speaking of IE6 or later versions?

RS: Don't just it by the incomplete implementation

SF: It does work in Chrome

JS: Nothing else does lol

RS: I will ask FS to fix the problem with FF

SF: It is about the implementation, it would be simple to say that if the ID ref is attached to a link, then the AT could give the user the ability to get that link, that would be better

RS; I agree

SF: I would like to see an improved aria-descrbedby, more versatile
... Longdesc should not go away

JS: That is the question

RS: Aware of multiple step process

<Zakim> MikeSmith, you wanted to suggest we gauge implementor support, and also harp on the "choose our battles" point

<richardschwerdtfe> scribe: richardschwerdtfe

mikesmith: implementation support is the deciding factor
... if we are going to go forward with this we are going to need to get buy in for it
... we have a lot of issues we are trying to get agreement about for html 5. We need to establish a priority

<oedipus> http://ie.microsoft.com/testdrive/ (IE9 test page)

<Joshue> +q to ask why not give longdesc the functionality that aria-describedby and drop aria-describedby that would then be a native solution?

janina: we need to come to s decision

<oedipus> http://www.w3.org/html/wg/tracker/issues/30

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

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

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

we need to come to a decision on longdesc

Cynthia: So, I think first off I am not going to fall on my sword over longdesc
... this hidden metadata is an issue

<Joshue> -q as Cynthia has brought up the issue

Cynthia: I think there are solutions to the hidden metadata issue. There are strategies to render the hidden metadata

<Joshue> -q

<MikeSmith> I like oedipus term "discoverable metadata" rather than "hidden metadata"

Cynthia: longdesc is part of a greater problem that needs to get solved.

<oedipus> can you live with "discoverable metadata" MikeSmith?

<MikeSmith> oedipus, yeah

<oedipus> rock'n'roll

<MikeSmith> we need to socialize that wording more

<oedipus> absolutely

<Joshue> +1 as the issue she raises touches on other domains

<Joshue> RS: Could people live with the two step process?

<oedipus> no, 2 step process for described-by is a 2010 D-Link

<Joshue> JS: Do we need a method to support a long description?

<oedipus> PROPOSED RESOLUTION: There is a need for a terse and long descriptor

<oedipus> PROPOSED RESOLUTION: There is a need for a long descriptor

Janina: do people agree we need to get to a long descriiption?

<oedipus> PROPOSED RESOLUTION: There is a need for a long descriptor mechanism

RESOLUTION: There is a need for some mechanism that supports longer descriptions

<oedipus> GJR thinks 2-step process with aria-describedby (pointing to a link to long description) is nothing more than a 2010 version of D-Link

<MichaelC> I agree

<oedipus> what about those who need side-by-side exposition of long descriptor and image?

Janina: Can people live with a two step process which would mean an aria-describedby to a link?

<cyns> me too, but don't it's the end of the world

josh: If the user who has an AT has a table

<oedipus> GJR says 2-step is too much

<oedipus> doesn't alleviate the problem (external or internal exposition) nor address those who need side-by-side exposition

<oedipus> GJR cannot live with 2-step process - D-Link even less implemented than LONGDESC and isn't intuative

josh: could we pimp longdesc?

<oedipus> great point, chaals

<oedipus> describedby is NOT the way of the future - it is part of a BRIDGE -- ARIA 1.0 cannot be ossified; need native semantics in host language

chaals: describedby is the future ... but it's a generalisation of longdesc (which currently doesn't have the same functionality). Learning from longdesc as an evolutionary path towards getting aria-describedBy to work properly seems more intelligent

Michael: can we support a two step process?

<oedipus> GJR would like straight-up-and-down vote along MCooper's lines

<oedipus> i OBJECT to mandating aria-describedby -- the solution MUST be native

<oedipus> maciej's proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning

<Joshue> Thanks for the URI GJR

<oedipus> plus 1 to Cooper's plan

<oedipus> GJR: plus 1 to support for internal description

RESOLUTION: People agree to have in page descriptions

<oedipus> GJR: plus 1 to support for externally linked description which can be exposed as per user preferences

<MichaelC> Do we want support for internal (in-page) descriptions?

<MichaelC> Do we want support for external (out-of-page) descriptions?

<MichaelC> Do we want to continue to support longdesc?

<MichaelC> Do we want aria-describedby to replace longdesc?

<MichaelC> Do we want another feature to replace longdesc?

<MichaelC> Can we live with a 2-step process?

<MichaelC> Do we prefer a 2-step process?

<MichaelC> Do we want to work on longdesc in preference to other features?

<oedipus> GJR: plus one for continued support for longdesc

<oedipus> GJR: aria-describedby is a TECHNIQUE, not a solution; ARIA is a bridge, not a cure-all

<oedipus> GJR: even an external resource can be embedded or displayed in document that contains image

<oedipus> GJR: work with the devil we know -- LONGDESC

<oedipus> GJR: NO to a 2 step process

RESOLUTION: Group agrees that we should have out of page descriptions but has concerns about its implementation

<oedipus> GJR: work on LONGDESC -- that is where effort has been concentrated

<oedipus> GJR proposes that we answer Cooper's questions

Cooper: do we want to continue to support longdesc?

<oedipus> plus 1 to continue to support LONGDESC

<oedipus> minus one for aria-describedby as replacement for LONGDESC -- aria-described is a technique, not a solution; ARIA is bridging tech, not an ossified solution

<cyns> I don't object to it, but don't really support it either

<cyns> -1

<oedipus> yes, we want LONGDESC until something proven to be better comes along

<cyns> -1 was to longdesc in html 7

RESOLUTION: The group wants longdesc to continue in HTML 5

<oedipus> GJR wants LONGDESC until something proven to be better comes along

RESOLUTION: The group does NOT want longdesc to continue indefinitely although there are some objections

<oedipus> minus one for aria-describedby as replacement for LONGDESC -- aria-described is a technique, not a solution; ARIA is bridging tech, not an ossified solution

<chaals> [I agree with GJR's desire for longdesc until something better comes along... and hopes we can get there with ARIA 2 and HTML 6...]

RESOLUTON: Do we want aria-describedby to replace longdesc?

<oedipus> GJR: minus 1 - it is a technique

<oedipus> [i agree with chaals' agreement with me ;-)]

<cyns> don't object to or support aria-described by to replace longdesc. no api for structured text alternative.

<cyns> I guess you could call that implementation concerns again

RESOLUTION: We do want aria-describedby to replace longdesc.

<oedipus> GJR objects to aria-describedby as replacement - it is just a TECHNIQUE

<chaals> [/me notes that there is a serious issue caused by having to use HTML and not XHTML as the likely format of a long description]

michael: do we want a new feature to replace longdesc in HTML 5?

<chaals> [/me thinks that if we add aria-describedBy into HTML then it stops becoming a technique and becomes native markup]

<oedipus> [but what about ARIA 2.0 - will HTML5 be trapped forever supporting ARIA 1.0?]

<oedipus> we need a method that works for those who have never heard of ARIA and who DON'T want to read another long spec to make HTML5 accessible

<chaals> [anyone who has read the HTML5 spec can happily read another tiny 200-pages... ;) ]

<oedipus> we also need a method for those who don't use AT and can't take advantage of describedby except perhaps through CSS

<oedipus> [ROTFFL]

<oedipus> cyns, discoverable data, not hidden

RESOLUTON: we do not want to ask for a new feature in HTML 5 to replace longdesc

<cyns> oedipus, but it's not really discoverable for a lot of people right now. That's the problem I'm trying to solve.

RESOLUTION: we do not want to ask for a new feature in HTML 5 to replace longdesc

<oedipus> cyns, that's EXACTLY what we should be concentrating on!!!

RESOLUTION: We do not want to change aria-describedby in the ARIA 1.0 time frame

<oedipus> plus 1

RESOLUTION: aria-describedby should be enhanced in the ARIA 2.0 time frame to support external descriptions (out of page)


<oedipus> plus 1 (including support for CURIES!!!)

<oedipus> NO to 2 step process

<cyns> still have implementation concerns about that, but we can talk about that during aria 2.0

<cyns> can live with it

<cyns> no objection

<oedipus> GJR OBJECTS strongly to 2 step process (2010 D-Link)

<oedipus> no to 2-step solutions of any type

<oedipus> i can live with that

RESOLUTION: We can live with a two step process but we do not prefer it

<oedipus> agree with cyns - tie to larger issue of "discoverable metadata"

cooper: do we want to prioritize to push longdesc in HTML 5

janina: we will come back to longdesc later in the discussion

<oedipus> canvas and longdesc are equally important for HTML LC

<Zakim> oedipus, you wanted to ask if ARIA 1.0 becomes a hard-coded part of HTML5, how will support for external resources with describedby be implemented

RESOLUTION: come back longdesc later in the face to face

<Joshue> Scribe: Joshue

<Marco_Ranon> Birmingham is famous for indian food!

<SCain> Tonights restaurant is the Brasserie at Malmaison. Here is the link http://www.malmaison-birmingham.com/indulge/brasserie and there is a link to the pdf menu on there

<cyns> josh sounds like a screen reader!

<cyns> have fish n chips for me ;-)

<Zakim> cyns, you wanted to say I don't object to new feature, but don't think it's the best use of our time to engineer one. It could be less time-consuming than fighting for longdesc.


JS: We have some suggestions from a group of us that have looked at this issue. It was PF, WCAG ,ATWG etc.
... This is an important feature in HTML, we looked at solutions for both long and short solutions etc.
... The guidance from the WAI group on alt (published last april), do we want to accept that or look at a change proposal?
... Do we agree, do we want to change etc?

RS: What is the current thinking?

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

JS: That it should stay, there are some things in the WAI guidance doc, we can put the URI into IRC, we can look at Lauras change doc also.
... Lets look at the WAI report and then at Lauras change proposal

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

<oedipus> http://www.w3.org/html/wg/wiki/IssueAltAttribute#Proposed_Solutions

MS: I want to note that there has been no disagreement about whether alt should stay or not, but if it should be required and what the spec should say.

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

RS: This will come down to validation.
... Most content is generated when text gets to the browser.
... Do we leave it up to the rules?
... WCAG 2 is being used by gov departs around the world, alt will be required.

<oedipus> WAI CG Consensus Resolutions on Text alternatives in HTML 5 (2009-06-10) http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

JS: To meet government requirements?

RS: Yes

SC: Yes

CMN: It is not a question of conformance, the spec will not be the motivation.

RS: <describes some 508 cases in the case>

Chaals: But that is only a part of the web

RS: What about if the UN convention gets adopted? etc WCAG is the standard and will be harmonised.
... Don't fight for alt to be required as this is a push on the validator

JS: Non-conforming pages will will, as regs say you gotta have it.

MS: We do care what the spec says, it isn't restricted to saying if it is required or not.

<cyns> I can hear MikeSmith too

<Zakim> MikeSmith, you wanted to say that we do care what the spec says

MS: The spec goes into usage details.

<oedipus> WAI CG Consensus Resolutions on Text alternatives in HTML 5 (2009-06-10) http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

MS: I hope that this info will be moved to a more appropriate space
... Its not about if it is required or not.

<cyns> +1 to moving detail to more appropriate places!

MS: There may be conflict with guidance in WCAG or other places.
... Also if the spec guidance should be there or not.

SF: I have it in the change proposal.
... It should come out.

RS: What it is?

Chaals: This stuff should be ripped out of the spec.

SF: Its about author conformance guidelines.
... There are conflicts

<oedipus> plus 1 to js' proposal to split issues

JS: This should be split as two issues.
... The technical aspects and guidance from the spec

<oedipus> WAI CG Consensus Resolutions on Text alternatives in HTML 5 (2009-06-10) http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

<MikeSmith> HTML5 spec "Requirements for providing text to act as an alternative for images"

JS: Any guidance should be pointed to in WCAG and not be independent. Even just for having one source.

SF: But Ian will say that alt is not just about a11y but Universal Access.

JS: Another reason to split them.

RS: talking of <canvas>, browsers that support a11y - we could state that authors must do x and then deal with alt in the same way, while referencing WCAG. Would that work Mike?

SF: The conformance requirements are about guidance for authors.

RS: Isn't that in WCAG?

JS: Yes also in HTML 5 spec?

SF: What is in the spec is largely the editors idea of these things?

<oedipus> http://dev.w3.org/html5/spec/text-level-semantics.html#alt

RS: We will just have to tell Hixie that this is the way it should be.

JS: There is a W3C spec, this is a maintanence question.

<oedipus> HTML5: "Except where otherwise specified, the alt attribute must be specified and its value must not be empty; the value must be an appropriate replacement for the image. The specific requirements for the alt attribute depend on what the image is intended to represent, as described in the following sections"

JS: Is there anything in the supporting techs for alt that we need that isn't covered?

<oedipus> WAI CG Consensus Resolutions on Text alternatives in HTML 5 (2009-06-10) http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

RS: What is the change proposal?

<oedipus> http://www.w3.org/html/wg/wiki/IssueAltAttribute#Proposed_Solutions

MS: Re: Rich's question. We have a discussion on authoring conformance in the spec, I think the spec should not define things in what authors should do but what docs should do.

Interesting point

MS: You should be able to validation the doc seperately from the author, teh DOC must, not the author.

<oedipus> mikesmith, the URI you pointed to in the HTML5 spec states: "Except where otherwise specified, the alt attribute must be specified and its value must not be empty; the value must be an appropriate replacement for the image. The specific requirements for the alt attribute depend on what the image is intended to represent, as described in the following sections"

MS: So we should look at doc conformance and not author conformance.

<Zakim> cyns, you wanted to say that validation warnings on alt have been a major teaching tool

MS: There could be changes in the validator behaviour to show an error where it currently does.

CS: I want to talk about alt being required.
... This is a teachable moment etc.

<oedipus> it also helps that in an alphabetic list of attributes for IMG, @alt comes first!

<MikeSmith> oedipus, yep - the "Except where otherwise specified" qualifier is the core of the issue

CS: Rich is right, sites will do it, but that it shows up in validation is valuable to teach developers about a11y.

<oedipus> mikesmith, agreed

CS: I disagree that it should not be empty setting null alt is very useful.

+1 to Cyns

RS: I am not sweating that alt is required.

SF: The concensus doc agreed that we (sic) said it was acceptable that there was not alt under some circumstances, such as aria-labelledby etc.

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

SF: So there are some cases where this is ok, and we have documented them.
... It sounds like we are going back to a basic issue that we already agreed on.

<oedipus> @alt and aria-labelledby are not mutually exclusive, provided content is same

SF: The issue is that they are circumstantial. Both have been rejected because we agreed that HTML conformance should not be defined in ARIA.
... That is a layering violation.
... Should we go back to the discussion that no alt should flag a warning etc?

SH: This is a deviation, we have <video> and <audio> alt and longdesc will have to be included in this.
... Because, you can have a short description for pieces of audio, and a transcript for longer pieces, the transcript etc is not covered.

SF: Can you not do this?

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

SH: A fallback is for where content is not supported.

Chaals: We should talk about this tomorrow.

SH: I wanted to bring it up.

<Zakim> oedipus, you wanted to say @alt has to be required by default with enumerated "exceptions" and techniques to mark such "exceptions" as presentational

GJR: Strong +1 to having alt by default.
... alt and aria-labelled by are complimentary and not mutually exlusive.

Chaals: I agree with Cyns, a null value for alt is needed.
... THere are two possible errors, 1) that there is no alt or equivalent 2) where there is bad alt included for conformance.
... We need to disambiguate these cases.
... The second is harder to fix.
... The teachable moment is important, but it is better to leave it broken that to fix it by adding a useless dummy text.

MS: I wanted to ask GJR, what do you mean about exceptions?

GJR: Role = presentataion

MS: So it would be ok to not have a role on the att?

GJR: Depends on context.
... alt ="" is ok if role = presentaion

+1 to GJR

<chaals> +1 too

MC: This refs WCAG which allows role = presentation so alt can be ommitted.

MS: So can it be an empty string?

<oedipus> http://esw.w3.org/PF/XTech/HTML5/DescriptorRequirements

Chaals: The attr can be absent.

Does that not trigger heuristics in the AT?


<Zakim> MikeSmith, you wanted to ask oedipus what he means by "exceptions"

MC: The presence of alt = pres shows more intention.

MS: Are there other exceptions?

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

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

Chaals: They are in change proposal.

<cyns> alt="" and role="presentation" do the same thing in API mappings. That works in some browsers now and should be standardized.

<cyns> they are equivalent constructions

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

SF: Some ARIA stuff was rejected because of layering.
... The idea is that ARIA conformance shouldn't effect HTML.

<oedipus> sean, re: your point about video and audio, i tried to propose a generalized standard approach to multimedia elements in HTML5: http://esw.w3.org/PF/XTech/HTML5/MediaSpecificElements

RS: I say that is included in HTML 5.

JS: So it becomes an issue in HTML 5 as it is included.

RS: This is good for ATs.
... Are you saying, if you don't have role="presentation, or null?

SF: I am happy with either.
... Laura submitted them.

<oedipus> role="presentation" and alt="" but NO alt="" without role="presentation"

SF: They are illumuinating.

RS: Role=pres is more precise.

JS: Do we want to endorse Lauras change proposal or our previous recommendations?

<oedipus> mikesmith, does this make sense? PROPOSED: role="presentation" and alt="" but NO alt="" without role="presentation"

RS: Null alt is a hack, role="presentation is a part of the host language and the alt text has to have meaning.

CS: You can't validate that.

<MikeSmith> oedipus, I think the argument against that is, alt="" and role="presentationentation mean the same thing, so you don't need both

CS: If WCAG has that as a technique thats fine.

RS: Role=pres takes the object out of the DOM tree.

<oedipus> mikesmith, role="presentation" is for AT hooking -- if alt="" i want to know about it, if alt="" AND role="presentation" are defined can skip over anything marked role="presentation"

CS: Some browsers do that already.

SF: Some say that may not be the right behaviour.

<janina> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126

CS: It is reasonable to leave alt out when role="presentation is present.

<MikeSmith> oedipus, I see

RS: It is not required that browsers take it out of the tree.

SF: Role = pres == alt=""

RS: For image only?

SF: Yes

RS: The difference is that some browsers take it out of the tree but that is not stated in the spec.

GJR: That is the role of presentation.

RS: Yes
... But they are not the same.

GJR: If there is a null alt I may want to query it, but with role="presentation can set my AT to ignore anything marked role="presentation".

CS: We need it because it is a part of ARIA.

<oedipus> s/means i will ignore it/can set my AT to ignore anything marked role="presentation"/

MC: re: text alternatives role="presentation is more explicit about author intent.

RS: It drops the object from the tree, they are not the same.
... Ian will say they are the same, but they are not.

JS: Both are needed.

<oedipus> if author uses alt="" should generate an error if role="presentation" is NOT present

MK: What does the AT do if the alt tags are not there?
... Does it mean that alt=true if some alt is present?

<oedipus> mk, most screen readers will say "image" or "graphic" but it is up to individual user settings (tell me about unlabeled graphics, don't tell me about unlabelled graphics

CS: Alt is not defined as a boolean attribute

Chaals: We cannot magically process stuff.

JS: We will talk about heuristics later.

<discussion on heuristics>

<oedipus> mk, several screen-readers offer a cascade order if @alt absent - @title, @src, @href (if hyperlink)

RS: Can we right this so, if presentation is provided you don't need alt on an image?

MS: Yes, the RELAXNG schema allows this?

RS: Why don't we do this?

Chaals: Thats in there!

<oedipus> if author uses alt="" should generate an error if role="presentation" is NOT present

<cyns> url for change proposal?

MS: I don't think there will be disagreement that if you have role="presentation then it is ok to not have alt.

<kliehm> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126

SF: What about layering violation.

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

JS: We have answered that!
... It is not a violation.

MS: ARIA is a part of the language, so there is no violation.

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

SF: But ARIA is only for AT!

JS: It doesn't have to be.

<laughs all around>

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

JS: Do we want to support the change proposal?

SF: I want to in principle, but we need to look at it.

RS: I am reading it but it is not quite right.

<Zakim> oedipus, you wanted to ask if can clarify if http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 is change proposal we are discussing

SF: Does this meeting support the WAI adhoc document?

<oedipus> GJR supports WAI CG Ad Hoc document


<cyns> strong +1 to http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

JS: Lauras doc may be technically wrong but we can support the intent.

<cyns> I do not suppor the missing attribute. The rest looks ok.

Chaals: Lauras doc does support a <missing> attribute and I don't support that.

<chaals> +1 to cynthia

JS: We can fix editorial imperfections.

<oedipus> do not support missing attribute but support the Ad Hoc CG proposal

<MikeSmith> for the record, HTML WG issue 31, title: "What to do when a reasonable text equivalent is unknown/unavailable?"

<oedipus> 1.<img> is only valid when at least one of the following is true:

<oedipus> ◦@alt is present (empty or non-empty) OR

<oedipus> ◦@aria-labelledby is present (non-empty only) OR

<oedipus> ◦the <img> is located within a <figure> that has a non-empty <legend> OR

<oedipus> ◦@role="presentation"

RS: In the WAI CG, we are missing stuff

<cyns> We have reached the following consensus concerning "automatically generated" alternative text:

<cyns> In order to address both the validity and human generation concerns, we do not oppose the creation of 'autogenerated' and 'missing' attributes where either one of these could be used to make an image that does not have any human-generated text alternatives valid. (Note: It is important that this marker is not included in the alternative text string itself.)"

<discussion on what is/isn't in the WAI CG doc>

<oedipus> aria-labelledby MUST be equivalent to the value defined for @alt

JS: It sounds like we support the WAI CG ad hoc but there are a couple of things missing.

<oedipus> if @alt is missing or empty without role="presentation", then implicit role="image"

<discussion on alt>

RS: I would prefer that there are no hacks, like alt null because we had no solution. I prefer that we explicitly state that it is presentational.
... This is better as we didn't have this in HTML 4 etc.
... So null alt is a hack.
... Cyns would that work.

<Marco_Ranon> i think alt="" should stay for legacy reasons

CS: I would prefer that the spec didn't talk about what alt should be at all.

<oedipus> alt="" should stay as long as role is used (presentation|image)

CS: HTML should say that alt should just be a string and for guidance look at WCAG.

<general agreement>

MS: I think we can get the chairs to support this in principle.
... I don't think this is the issue however.
... The case we have argued about is what to do when you are not able to have alt text for an image, such as Flickr or a Webcam.

<oedipus> flickr case is an authoring tool/aggregator implementation issue, not a markup issue

MS: Streaming media etc, what do you do?

JS: The first we addressed in the WAI ad hoc.

MC: This is a WCAG issue.

MS: No its not.
... The position is that it is harmful to try to mandate alt text in those cases as people will just dump rubbish text to pass validation.

<oedipus> flickr case is a red herring - there should be a MEANS of adding real @alt text to flickr/aggregator images

<Zakim> MikeSmith, you wanted to remind that the core of the disagreement about making alt required is not about presentational cases, but instead about the "What to do when a reasonable

SF: I have looked at this, 1) the webcam etc is part of a link 2) also there is some text such as the date etc within the image. That info should be included as a text alt.
... that should at least be there.
... So the cases where there cannot be something is less than you would think.

<Zakim> MichaelC, you wanted to say that the use cases relate to unknown / unknowable text alternative; better to provide a mechanism to explicitly state that than rely on absence of alt

MC: The issue is where the alt text is unknown and may unknowable. This could be addressed by stating that the alt is unknown.
... This would be explicit.

MS: So omitting the alt is not a confusing semantic.

<Zakim> cyns, you wanted to say WAI doc 'doesn't oppose' missing attribute. We don't want to add it. IIRC, we were saying that we won't fight about it, but we don't want it. should

<oedipus> flickr case is a red herring - there should be a MEANS of adding real @alt text to flickr/aggregator images, if nothing can be done automagically at load, then burden on authoring tool/aggregator to make annotation (terse and long) mechanism available to the individual author

CS: Most of Lauras proposal is about missing, so remove that and move it to a separate change proposal.

GJR: The Flickr case is a red herring.
... I mention it as the HTML WG will come back with an objection.

<cyns> Agree that there are solutions to the flickr case. That's why I want to separate the non-controversial presentation stuff.

MC: The "I don't know what the alt should be" will support that.

Chaals: I repeat what I said at the beginning (see beginning).
... Don't fix validation problems with dummy text.

<oedipus> cyns, are you working off of http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 or http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc

Chaals: That is worse, the indicator for this should be that there is not alt attribute.


Chaals: Either is a useful attribute or nothing there.

MS: <echo> Chaals
... Omitting the attribute is the way to do this.
... Using the <missing> attribute will mean that this will be used just to shut up the validator.

<Zakim> MikeSmith, you wanted to respond to MichaelC

MS: We won't get agreement to have alt required in the HTML 5 WG.

RS: I think we should say that if you know that it is presentational state that. Leave it to WCAG to define the alt.

<oedipus> for legacy purposes, alt="" needs to be mapped to role="presentation"

<oedipus> JOC: completely agree with chaals - problem about leaving out @alt is that with current AT, missing alt will cause problems for users -- rather have concrete way to bypass whether using role="presentation" -- pushing that is best

<oedipus> HTML5 should point out that use of spacer images is forbidden and should be controlled by CSS

RS: I could live with that. Make it simpler on the author etc. If not possible follow WCAG 2. alt is only a part of the discussion. alt is the thin end of the wedge.

<Stevef> GJR: it does sorta

RS: Is alt required on image maps etc?

<Zakim> MichaelC, you wanted to say I agree not providing alt attribute is a simple way to say "I don't know it" but it's not an explicit way and to say but I can live with relying on

<oedipus> yes, @alt on imagemap areas is still needed

MC: Re: Omitting, is that it is simple but the problem is repair. I can live without it. Alt text is an issue of completness.
... <shows examples on screen of various images with/without alt text>

<Laura> Requiring a set of programmatically valid options helps ensure that images have complete structure. Complete structure requires both src and text alternatives.

<oedipus> strong plus 1 to MCooper's conclusion - alt is as necessary as src

<Laura> src is to sighted users as text alternatives is to some users with disabilities.

<oedipus> yes!

MC: Alt is needed as an image of completeness.

<Laura> * Omit the src attribute and sighted users have no content.

<Laura> * Omit text alternatives and some users with disabilities have no content.

<Laura> Without both a src and a text alternative the <img> element is incomplete.

SF: Gez would make that arguement also.

<SCain> +1 to MC conclusion too

<cyns> +1 MC

SF: I don't understand your point Chaals, should the validator warn?

<cyns> how long is lunch?

<Sean> modern images should support metadata what if the alternative is in the metadata

<SCain> 1 hr

JS: Lets talk about this after lunch.

<chaals> It is a problem not to have alt. But the problem is one of not knowing something. Telling lies is a more serious problem, so it needs to be clear that just inserting something to stop the warnings is worse than leaving it off.

<oedipus> you can't keep people from lying -- except for me, of course!


<MikeSmith> oedipus_away, we are starting up again

<Sean> is the meeting room dialled in yet?

<SCain> can anyone hear us?

<Sean> silence here...

<MikeSmith> Agenda

<scribe> Scribe: Sally

<oeddie> scribenick: SCain

<MikeSmith> MichaelC will scribe from 15:45

MC: Agenda has been updated

<oeddie> fwiiw ported 2 pages from ESW wiki to HTML A11y TF wiki

<oeddie> http://www.w3.org/WAI/PF/HTML/wiki/MediaSpecifcElements

<oeddie> http://www.w3.org/WAI/PF/HTML/wiki/RoleAttribute

Image heuristics

<MikeSmith> HTML WG Issue 66

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

<cyns> P2 is me

MS: Issue 66 from HTML WG

JS: Do we want to accept any heuristically generated alt is part of the issue

<oeddie> NO

MC: Do we want to rely on it?

<MikeSmith> http://www.w3.org/html/wg/wiki/ChangeProposals/ImageHeuristics

MC: Change proposal posted

MS: Matts change proposal is to remove the paragraph in there from the spec

<MikeSmith> Change Proposal: Remove Image Heuristics Paragraph from img Element Section

CMN: great idea

<oeddie> GJR plus 1 to removing paragraph from spec

JS: I think we should make suggestions

<cyns> +1 to removing paragraph

MS: We should see Hixies comments

<Laura> ISSUE-66 Change Proposal: no change http://lists.w3.org/Archives/Public/public-html/2010Mar/0194.html

<Laura> Ian's Be more explicit about potential repair techniques http://lists.w3.org/Archives/Public/public-html/2010Mar/0195.html

<oeddie> matt: "This text should be stricken, because it gives the message that this is viable now, and a reasonable substitute for @alt. Neither is true. "

LC: There were two change proposals

<Laura> Accessibility Change Proposal Status: http://www.w3.org/WAI/PF/HTML/wiki/Accessibility_Change_Proposal_Status

<oeddie> matt positive effect 1: "Removing the text will remove the misconception that image analysis can currently be used to recover from images with missing text alternatives."

<oeddie> matt positive effect 2: "Removing the text will remove the potential creation of an HTML language feature that is only offered by one provider, and is only available in the cloud."

MS: This is a rational statement
... We do want implementers to try to innovate in this area

<Sean> Implementors of authoring tools can innovate too

MS: Even browser implementors

CMN: IS there any value having this text in the spec?

<oeddie> GJR proposes that there is NO value in having any image heuristics verbiage in spec

MC: Should image heuristics become useful in the future then we might support it but not at present

JS: I am not sure if we should rest this with implementors

CMN: Propose we should vote for Matt Mays proposal

JS: I second that

MS: It would be useful that the people involved in the discussion have read Hixie's proposals

<oeddie> yes, i have read hixie's counter-proposals and reject them

CMN: We have read it

<Joshue> Josh: This proposal is touching on AI, and I don't think that the HTML 5 spec is the place for it.

<oeddie> GJR plus 1 to accepting MattMay's proposal

CS: The counter proposal from Hixie does not address the core issue in MM proposal which is around expressing author intent.

<Zakim> cyns, you wanted to say that *anything* in HTML 5 about what the string in the alt attribute should contain is a slippery slope. don't go there.

CS: I can see a place for heuristics in an authoring tool but having it as a repair technique in a UA seems risky

MS: Propose we take these one at a time

<Laura> Inclined to cut the section as it could very well be confusing to authors and used as a loophole not to write text alternatives.

MS: If this is removed are implementors not going to innovate

<oeddie> if pigs fly in the future, we can support that too, but we don't have to state so now

JOC: Not at all
... The domain that this solution comes out of might have nothing to do with the web

SC: I agree

CS: Not putting it in the spec will not cause anyone not to do it if they were going to do it
... Filling in the attribute is not something the spec should be doing

<Laura> If in fact anything is needed, I'd suggest simply using something like: "For User Agent advice on techniques for repairing missing content

<Laura> please refer to the User Agent Accessibility Guidelines."

MS: It is a consistent position in that regard

<oeddie> agree with Laura - point to UAAG

CS: It is about the value of alt

SH: Images do have other information in them. I would suggest we put a mechanism for taking the metadata from the image

MS: There are other places it could be done, that is one place

<oeddie> sean, yes, extraction of meta-data should be highlighted -- canned images could have terse and long descriptors attached to them

CS: You could have AT that do image analysis

<oeddie> the image analysis tools available i have found less than useful

CS: Does not neccesarily make sense for it to be part of the browser

MS: I am hearing that this is not essential to the spec. Anyone object
... We should look at a second proposal

<oeddie> we should let Matt speak for Matt

MS: So adding more text...

CMN: I would choose matts proposal over Hixies

MK: Does it have any copyright if it is written in a spec, Google cannot claim copyright

MS: no issue around this

MC: This is defining use cases

EC: Does not make any difference if it is in a spec or not

MS: We need to have a statement of reason why

MC: This is a list of use cases that does not belong in a spec but a requirements document.

SF: They do not need this text to be told

MS: Spec is already really big and this is meant to be a fucntional spec for implementors.
... This guidance is not essential to doing that. This is a reasonable stance to argue. That this is not the proper place for this

CS: Still better not to touch on it at all. Image analysis not html at all

<oeddie> strong plus 1 to cyns

<MichaelC> We would not normally take time to object that this exists even though it goes beyond what a spec needs to provide, but we are concerned that it could mislead authors into believing they can rely on this when the current state of technology does not support that

<oeddie> plus 1 to supporting MM's proposal full stop

RESOLUTION: To support Matt May's change proposal

<oeddie> plus 1

Table Headers

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

MC: I think we wanted to review and think that we are OK with this

<MikeSmith> Accessibility of Table Header Structure

MC: various bugs
... Bug 8449

<cyns> link please?

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

MC: Shelly has a change proposal for this
... When were we going to look at that?

JS: We were going to look at the ones that were in scope
... We had strong opinons on pf call

MC: This is moved new topics
... Table headers done?

LC: The test suite and this has gone to the other task force

MC: A joint call with the testing task force at some point would be good and MS, JS and I have discussed this

LC: Good idea

JS: Action that this comes up in a managerial discussion

MS: On table headers, do we have an open issue for this in the WG now? Are any of the related issues open?

<MichaelC> ACTION: cooper to organize joint discussion of testing task force and html a11y task force [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action01]

<trackbot> Created ACTION-22 - Organize joint discussion of testing task force and html a11y task force [on Michael Cooper - due 2010-04-13].

MS: We are fine, they are closed

Resolved and closed bugs

<MikeSmith> http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0046.html

<MikeSmith> Weekly Resolved & Rejected Bugs Report

LC: This is what happened last week

MC: Will come back to Bu 8171 implement text alternatives proposal

LC: Bug 8716 - this is related to the change proposal

MS: Why do we need both bug and change proposal

LC: I was asked to by the chair
... Most have change proposals

MS: We can deal with the bugs by talking to maciej
... Change proposals that are related to issues

<Laura> http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0009.html

<Laura> Help with text alternative bugs related to HTML5 Change Proposal: "Replace img Guidance for Conformance Checkers"

<chaals> [rehash of how process works in the HTML group]

JS: There is a W3C process will be honoured

MS: We have three experienced chairs who are managing the group and we are in a good place for getting things done.
... I think we should look at whether there is anything here that requires action
... We will go through the bug list tomorrow around this time
... Drag and drop tomorrow


MS: No Nav is on the chairs radar now

RS: It is more of a clarification for the spec

<cyns> is there a link to the proposal?

<oeddie> http://www.w3.org/wai/pf/html/wiki/Canvas

MS: Other question is what the objections to it are?

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

SF: Ian says it is not needed and won't be used

<oeddie> http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Change_Proposal_Action_165

SF: Why do we need the attribute he is saying

<oeddie> http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility

RS: We have info to the opposite, the content is in the navigation

<oeddie> http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom

<Stevef> http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibilitynonav

RS: I do not think the point is valid

MS: Ian is unlikely to make the change to the spec without anything from the chairs
... I can try to talk to chairs about it

SF: There are other changes within the spec text that are equally important. It is specific about what a browser needs to do to implement it

CMN: I disagree with Hixie and RS
... My proposal is in theree

<oeddie> http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom

<Stevef> modified spec text for nonav http://www.paciellogroup.com/blog/misc/canvas/canvas-nonav.html

<oeddie> steveF, added link to nonav change proposal to http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals#Canvas_Change_Proposals

CMN: <outlining proposal>

<Stevef> Bug 9061 - allow image maps on the canvas element. http://www.w3.org/Bugs/Public/show_bug.cgi?id=9061

JS: We were agreeable to supporting that in addition to Rich's

CMN: The two things are not mutally exclusive.
... I have put it as a change proposal to replace nonav proposal

SF: More than that though?

CMN: There is the spec, rich's proposal which is an improvement and I think my proposal is a better (alternative) improvement

SF: focus rectangle and caret

RS: I refer to fallback content as this is in the spec, but I would have to make some changes for imagemap

<oeddie> focus rectangle and caret: http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility

<oeddie> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Proposals#Canvas_Change_Proposals

SF: There is another proposal - focus rectange and caret

RS: The mac when you are selecting text does not move the caret.
... Writing it up to say you have to track the last selected position or caret to drive focus. Then it will work on mac and windows
... Blink rate - issue around seizures
... I will put something in there around a typical blink rate.
... I have to work on focus rectangle. You also have aria -active descendant.

SF: The status is that you are updating it

RS: It will go to the canvas group then TF

MS: We do need to get moving on this

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

JS: How do we move forward between Chaals and Rich?

<oeddie> http://www.w3.org/WAI/PF/HTML/wiki/Canvas/Meetings/Minutes

MS: Blink rate is more recent?

RS: It is

<oeddie> http://www.w3.org/html/wg/wiki/AddedElementCanvas

CMN: Blink rate not connected to the other two proposals

MS: If it could be separated that would be good
... We have to prioritise

JS: Drag and drop is a major issue

MS: We need to get someone else to pick up drag and drop

<oeddie> http://www.w3.org/html/wg/tracker/issues/74

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

RS: I want to submit it to the canvas group for discussion next week while I am on discussion

MS: Can you send it to the task force group too

SF: I will shepherd it if I can

<Sean> In the <map> proposal. Should <area> support the role attribute http://www.w3.org/WAI/PF/HTML/wiki/RoleAttribute ?

<chaals> [Sean, yes]

<oeddie> [GJR agrees with sean that AREA should support the role attribute]

MS: We need implementor feedback on it

<oeddie> ?

MS: No action on focus ring part for now and we can look at proposal next week

<Zakim> Sean, you wanted to ask In the <map> proposal. Should <area> support the role attribute http://www.w3.org/WAI/PF/HTML/wiki/RoleAttribute ?

<oeddie> plus 1 that AREA should support the role attribute

<cyns> +1

SH: should <area> support the role attribute

RS: We will have to change the map proposal in html5

CMN: I can't find any implementation that matches the html5 version
... Going back to the html4 model does not seem like a big cost as it matches reality
... Started working on the edits, but I need to clean up the proposal

RS: Drag and drop on an image map with elements, does that impact anything? These are the things we have to think about

SF: As far as <area> is concerned. Currently in spec you can't have roles except link role and I think that needs to change. It needs to change if we are going to allow area to be used on canvas

EC: Canvas used for graphs anywhere there is a dynamic image.

CMN: We have used it to render UI controls

MK: Daily motion used it

CMN: They use canvas to reduce the overhead

MS: We can say that we want a solution for this and will not object to any reasonable proposals that are put forward.

<kliehm> I remember that the video controls in this example are rendered with SVG, so this is a use case to be expected in canvas, too: http://www.dailymotion.com/openvideodemo

MS: There are different levels for different proposals but we can say what looks promising and we will not object to them for further discussion in the working group

<chaals> [chaals steps out]

JS: Do we need chaals edits to be done?

CMN: We do

MS: If you have time to review CMN proposal that would be good

RS: That would be really hard because of time

SF: We don't have imagemap support on canvas and I have raised an issue in tracker

<MikeSmith> oedipus, yeah, back in 10 minutes

<MikeSmith> http://www.w3.org/WAI/PF/HTML/ftf_2010-04#agenda

MS: There is some work for individuals to do

SF: If I can be of help I will be

<oedipus> sean, we are back

<chaals> scribenick: chaals

<Stevef> Bug 9061 - allow image maps on the canvas element. http://www.w3.org/Bugs/Public/show_bug.cgi?id=9061

SF: To have imagemap work on canvas, needs to be in the spec.
... Put in a bug for that, editor rejected it.
... so I raised an issue.
... Maciej doesn't think Webkit would object.

<MikeSmith> WG tracker issue 105: allow image maps on the canvas element

<SCain> scribenick: SCain

MS: There is nothing more from TF we need to do on that

SF: We could say we support the idea

JS: You could see what response that gets

CMN: Works in the browsers

SF: If someone puts areamap on top of canvas the author intended to do that

RS: You have to be explicit - if we allow it to be on there it should override it
... Should we create two proposals?

CMN: That is the situation now

SF: I submitted an issue and that is where it is now, to allow to use imagemaps on canvas

MS: So we can be prepared with a proposal

<MichaelC> chair: Janina_Sajka, Mike_Smith

SF: Will try and do it before thurs

RS: Keyboard navigation information should be in there

Action Steve to write proposal for imagemaps on canvas

<trackbot> Created ACTION-23 - Write proposal for imagemaps on canvas [on Steve Faulkner - due 2010-04-13].

JOC: Are imagemaps key to making accessible canvas fly?

CMN: Because we know them and recommend to authors that they should do that then they will understand this

RS: Will have to do the same thing in canvas

CMN: You get keyboard nav, you get focus and people know imagemaps

RS: There no silver bullet

SF: But is a good basis

<Joshue> Josh: We still don't know how native HTML 5 semantics will play when embedded within <canvas> content.

RS: I think having two cases available will be good
... We have to submit a proposal as far as process goes

MS: Yes as Ian has rejected a bug
... Chairs look at the objections and have a discussion and send an email to Ian to say what should happen
... If chairs make the evaluation that it should be added then they make a specific request that it should be added to Ian.
... I don't think we need to worry about this one too much
... I will bring up NoNav with the chairs
... We have an obligation to get to last call within a reasonable amount of time. My role is to try to get us to last call sooner rather than later.
... We need clear milestones
... Working group is out of charter at the end of this year and we need to discuss what the new charter should say.
... Biggest set of issues for last call are the issues in the task force that we need to get done. We all need to work with a greater sense of urgency.
... Change proposals do not have to be perfect. We can always make refinements to them.

JS: There is no call on Thursday

MK: People are still going to produce things we haven't thought of.

MS: I think Bespin does not seem to have a lot of uptake so far

MK: Mentioned it on the google group

SF: I think it was an example of the sort of things people might do

<Sean> OK by me

<kliehm> Bespin will be used as editor for Mozilla Raindrop, but might not rely on Canvas in the future http://groups.google.com/group/bespin/browse_thread/thread/6595a8e227bf3987

Title attribute

<MichaelC> Tracker Issue 80

<MichaelC> scribe: MichaelC

<oedipus> i should be able to toggle between hyperlink text, alt, and title through direct query or as a means of listing links

<oedipus> @title is VALUABLE - it provides a "verb" to @alt's "noun"

sf: title attribute is not a good substitute for alt

it's not displayed by default visually

it's not device independent

<oedipus> @title is NOT a substitute for @alt -- @alt is a noun @title is a verb

spec says you should not display title in the same way alt is displayed

<oedipus> @title serves a different purpose from @alt

joc: does title have any use?

<oedipus> ToolTip is an implementation decision, not an inherent means of displaying content of @title

sf: tooltips, labeling form controls

especially in tables where a visual label comes from headers, but need individual labels for controls

question is whether title should be included in the algorithm for text alternatives

the change proposal says no

@@URL to change proposal

cs: title maps to a description

isn't meant to be name for an object

question of whether title should be conforming: no

whether it should be used if provided: maybe

sf: AT can use it

but the algorithm covers other types of user agents too

<Zakim> cyns, you wanted to say title is the accDescription, alt is the accName. Put another way, title is the tooltip, alt is the name

sf: e.g.. user using keyboard can't access title

<Zakim> oedipus, you wanted to say "failure" of "title" is due to lack of support by ATs especially screen readers; @title - the problem isn't the spec, it is the implementation

joc: shouldn't it be an element?

<Stevef> Modify img element section Change Proposal http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203

gr: AT haven't provided the functionality on title that they could

<Laura> title is advisory

e.g., ability to sort on lists of it

sf: sounds like we're all in agreement

<Joshue> +q

<oedipus> title could be displayed in status bar onFocus

<Zakim> chaals, you wanted to agree with Steve

proposing to remove title from text alternatives

cmn: user agents should enable access for keyboard users

though that is an implementation detail, not a spec issue

<oedipus> yes, @title is supplemental info, not textual alternative - @title is global, @alt is not

sf: Windows desktop does do an accessible implementation of tooltip

<Zakim> MichaelC, you wanted to say the ARIA accessible name algorithm takes account of title

<MikeSmith> scribe: MikeSmith

<Joshue> MC: You propose removing title from the text alternative computation?

Joshue, np

<scribe> scribe: MichaelC

mc: ARIA does include title as part of its text equivalent computation

rs: as a last resort

mc: do we want to harmonize these approaches?

sf: because title is last resort, we are just saying that it shouldn't be a resort from document conformance perspective

<Marco_Ranon> +q

joc: agree title shouldn't conform when alt present

but there are various mechanisms to describe images

what is purpose of title?

useful for tooltips, labeling form controls

but what is its use on images

what is future of title attribute in HTML?

ms: for images, or as global attribute?

<MikeSmith> HTML5 spec on the title attribute

<MikeSmith> http://dev.w3.org/html5/spec/dom.html#the-title-attribute

<oedipus> <img src="opera.png" alt="Download Opera" title="download Opera for Platform x (18.8 MB)">

rs: it's useful for the generic use case

cs: it's a secondary description or tip

mc: so title without alt is a secondary description without a primary description

<oedipus> complementary to use an ARIA term

mr: RNIB always advises against title because it's not always exposed

and screen magnifier can be problematic if tooltip pops up and occludes content

but there are recommended places such as forms

<Laura> The title attribute is used in addition to the alt attribute.

don't register a failure when used, though recommend a different approach

<oedipus> what about backwards compatibility, rich?

<Sean> maybe we should use title in its sense for a work of art

rs: perhaps humourously, proposing dumping alt altogether in favour of aria-label

<Laura> The title attribute can be used to add advisory information or to add flavor.

cmn: or reverse, dump aria-label in favour of title

<SCain> Backwards compatibility is a good point gregory

sf: aria-label doesn't have the tooltip behaviour

<oedipus> state "title is not intended to invoke a specific behavior, for example, exposition in a tooltip. title content could as easily be conveyed to the user via the status line"

rs: our goal is to transition people to new way on doing things

<cyns> oedipus, I disagree. behavior needs to be standardized.

continuing to support alt because we can't just throw aria-labelledby in place

<oedipus> cyns, my argument is that tooltip exposition (or exposition of title) should be a USER preference

<MikeSmith> as far as the title attribute in other markup cases, note that spec defines some specific semantics for the title attribute when it's used with the abbr element, input elements with the pattern attribute, the link element, and the meter element

<oedipus> good points, mTMs

ec: could mark title obsoleted but conforming, which means you can use it but don't count on it appearing in future versions of spec

<cyns> oedipus, maybe, but DEFAULT behavior needs to be standardized. Otherwise people will roll their own, and you won't be change their behavior

as opposed to deprecated which means it still works but you shouldn't use

<oedipus> cyns, agreed

<Sean> can we state to use aria until media metadata is reliable

rs: let's do this with title and alt

sf: currently it's accepted that ARIA is an AT annotation

<oedipus> sean, aria isn't native to HTML even if it is shoe-horned in -- it is not meant to be hard-coded

to say you should use it by preference, it won't be as accepted

now mainstream UA consumes ARIA, not just AT

<cyns> I have to leave at half past

rs: how many people load pages with images turned off?

<Sean> Is aria really not native to HTML?

<lots of people raise hands>

cmn: lots of places still have significant cost to image download

so turn off

<MikeSmith> cyns, will get to the queue momentarily

<oedipus> sean, ARIA is for more than HTML - it is a free-standing bridging technology, not a be-all solution

rs: @@

<Sean> I understand that, but isnt it being adopted into HTML. I thought Janina said that

cmn: ARIA says it's just for AT, but that should be stripped out of the spec

<oedipus> sean, that is a matter of contention -- if aria is hard-coded into HTML5 with no extensibility or namespacing, then i will formally object to hard-coding ARIA in HTML5

<Sean> ok

even so, relying on ARIA won't get us off the hook

<oedipus> mc, right -- that's the bigger point

<MikeSmith> cyns, after Rich completes this thought

<Sean> oedipus, time to introduce your <legend> element?

rs: we talked about expanding aria-describedby to fill full longdesc use case

<Joshue> oedipus is a <legend> lol

<oedipus> sean, perhaps, if you want to do it, i'm burnt out

<SCain> +1 to planning towards consistency

doing same with title and alt makes sense as a paralellel engineering

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

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

<Zakim> cyns, you wanted to say don't get rid of alt because of back compat both for existing content and because it's the one, single, bit of accessibilty technique that most web devs

ms: appears to make sense; need to test that proposal with entire task force

cs: important not to take out native attributes and replace with ARIA

alt is about the only accessibility attributes developers know about

removing those would be a dangerous step

rs: but the attributes would still exist for developers

for now

give time to learn about the new approaches

cs: don't think we should deprecate native attributes at all

ARIA is a bridge

developers who understand ARIA are at the top of the developer food change

those at the bottom have barely heard of alt

rs: but ARIA is declarative markup

needs to be used on custom controls

<Sean> ARIA plankton

no matter how many standard controls we have, there will be custom controls

ARIA allows those to be accessible

cs: img is a standard control

and alt is the standard approach for that

ARIA doesn't go away but shouldn't supplant that standard behaviour

joc: agree

cmn: design principle of using aria-label instead of alt makes sense

agree that this isn't the right time though to make such a big replacement

at least not in the HTML 5 time frame

maybe later

though ARIA could state more about its expected lifetime

rs: so how to do go gracefully go into standard way of enablement?

cmn: 1) scribe missed

2) get ARIA architecture really solid, implement the takeover

<oedipus> can't one use aria-labelledby and aria-label to connect a DT to its child DDs? (yes, i know there is an implicit binding, but aria makes it explicit)

then in HTML 6 the takeover is ready to plug into place

with all the cool examples

<Sean> what does aria-label bring that could not be added to the alt attribute?

rs: we need to state intent over time

cmn: but you state that over time

arguing now will create confusion

<chaals> MC: Agree with Chaals and Josh.

<chaals> ... think ARIA should be a bridging technology.

<oedipus> sean, aria-label can include "rich text" -- alt is just a plain text string

<Sean> but its still an attribute right? in which case that could be added to alt

<chaals> ... feel wierd about relying on aria attributes instead of native attributes, but seeing a phase-in plan makes it feel less troubling

<scribe> scribe: MichaelC

rs: there is probably more ARIA support by authors now than there is for HTML 5

<oedipus> aria-label in a SPAN can contain rich markup

<cyns> I still think it's the wrong direction. Aria is for cases where native elements and attributes fall short. It should NOT be used to replace existing ones.

<cyns> (and I lost my phone connection)

<oedipus> i agree with cyns

ms: we could probably get agreement about ARIA support in general

don't think we could get agreement on making alt and longdesc obsolete but conforming

because those features, it has been argued, are widely misused

<oedipus> sean, <span id="label1">This is <span lang="fr">de riguer</span></span>

we don't want validators issuing warnings about the existence of alt on an element

<Laura> aria-labelledby is an option in the change proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126

spec should clarify stance on aria-labelledby, aria-label, etc. in general

<chaals> [Laura, yup. As far as I can tell, that's not controversial, either]

should change the statement that they are accessibility-only features

<oedipus> aria-labelledby WITHOUT @alt should be an error

<Sean> aria-label (property) Defines a string value that labels the current element when included as an attribute of the current element

sf: the spec currently says they are annotations for AT

<oedipus> @alt and aria-label content should be the same, only with aria-label one can use markup

<little bit of discussion>

joc: I always thought ARIA would become a native part of HTML 5

rs: would object to entire spec if it didn't

<oedipus> if ARIA without extensibility and namespacing is added to HTML5 i will formally object

sf: it's clear that it's meant to, just that it says it's only for AT

<oedipus> ARIA cannot be hard-coded into HTML5 -- it defeats the purpose of ARIA

ms: we just need to expand that it's core and not just for AT

RESOLUTION: we do not accept @title as a substitute for @alt, in respect to document conformance
... support the change proposal at http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091203

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

<Stevef> http://lists.w3.org/Archives/Public/www-archive/2010Mar/0031.html

<Joshue> Scribe: Joshue

SF: Reads change proposal.

MS: Well we disagree with that.

SF: I thought there was a bar!
... Its not great.

MS: It is short
... We have a clear agreement from the TF and we support SFs change proposal.
... We need to look at what to do on the spec language that says the ARIA markup is only for a11y. Steve?

<scribe> ACTION: SteveF to raise bug on ARIA being restricted to a11y [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action02]

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

<scribe> ACTION: Stevef to raise bug on ARIA being restricted to a11y [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action03]

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

<MichaelC> scribe: MichaelC

<scribe> ACTION: faulkner to raise bug on ARIA being restricted to a11y [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action04]

<trackbot> Created ACTION-24 - Raise bug on ARIA being restricted to a11y [on Steve Faulkner - due 2010-04-13].

drop action 3

<kliehm> "A" for "alternative"?

rs: ARIA Implementers guide states that mainstream user agents should provide a way to expose landmarks

<oedipus> role in HTML is different from ARIA in HTML

cmn: Opera doesn't restrict its implementation to accessibility use cases

Text alternatives (continued)

js: Seems we're close and just need a group to nail it down

ms: reminder, when we go back to WG should expect major disagreement

don't think the people who argued to not make alt always required have changed their positions

js: validator should warn on some of the alt situations

ms: configurable validator to reduce noise

<Laura> Needs to be an error on a warning

cmn: if you can turn off warnings, the validator doesn't do its job

sf: <missed>

<Laura> In terns of the schema text alternatives need to me required.

ms: the schema will need to explicate requiredness states of alt

might not be too much of a spec change

ask a statement that conformance checkers should warn on images that lack alt attributes

this is new

don't think conformance checker warnings have been proposed to date

<Laura> Strongly disagree. Should be an error.

<Laura> Requiring a set of programmatically valid options helps ensure that images have complete structure. Complete structure requires both src and text alternatives.

js: the pushback would be on if it is required

<Laura> src is to sighted users as text alternatives is to some users with disabilities.

<Stevef> Add usemap attribute to the canvas element (change proposal) http://www.w3.org/html/wg/wiki/ChangeProposals/addimagemaptocanvas

mc: the issue is we want a shade of gray (warnings) but only black & white exist (error or no error)

<Laura> Omit the src attribute and sighted users have no content.

<Laura> Omit text alternatives and some users with disabilities have no content.

<oedipus> strong plus 1 to Laura "src is to sighted users as alt is to some users with disabilities or crappy equipment"

<Laura> Without both a src and a text alternative the <img> element is incomplete.

ms: validators check against DTDs

conformance checkers go beyond that

<Joshue> MC: Do we want to add this category of warnings?

<Joshue> MC: Would there be opposition?

<Joshue> MS: There is one.

don't confuse conformance checker requirements with validation

<Joshue> MC: This means that we want "conformance" as such

<MikeSmith> back at 3 minutes after

<SCain> My favourite place in chinatown in birmingham is http://www.cafesoya.co.uk/

<oedipus> http://en.wikipedia.org/wiki/Balti_Triangle

<oedipus> http://www.bbc.co.uk/legacies/immig_emig/england/birmingham/article_1.shtml

<oedipus> sean, laura, we're starting again

<return from break>

ms: objections to image without alt being a warning instead of an error?

<cyns> I object too

<oedipus> i object as well

lc: object; helps to ensure images have complete structure

<cyns> (but I'm ok with the exceptions in the change proposal)

mc: would making it warning instead of an error change that?

<Joshue> +q

lc: if lack of text alternatives was an error, alt could be just a warning as one of the options in the suite of possibilitiies

cmn: think it should be an error but can live with it being a warning

because of the balance between 1) an image not done right without a proper text alternative 2) an improper text alternative is worse

in the end, can live either way

lc: in language, incomplete without text alternative

cmn: also incomplete without *appropriate* text alternative

<oedipus> Laura (earlier): "Requiring a set of programmatically valid options helps ensure that images have complete structure. Complete structure requires both src and text alternatives."

<oedipus> ... "src is to sighted users as text alternatives is to some users with disabilities."

<oedipus> ... "Omit the src attribute and sighted users have no content."

<oedipus> ... "Omit text alternatives and some users with disabilities have no content. "

anyway, lots of conformance issues are arbitrary

sf: if there's no alt attribute, we get nothing

<oedipus> one can't validate the contents of a <p></p>

unlikely to win on an always error proposal

we can win on a warning proposal

joc: still support the WAI CG proposal

there may be use cases that alt not needed because other description mechanisms exist

therefore ok with warning as long as author notified

don't want to promote poor alt text to shut up validator

which maybe error does

<Zakim> cyns, you wanted to say that we should separate 'missing' from the presentational issues, and make 2 change proposals. Can we resolve that we're ok with the presentational stuff

cs: we're confounding two issues

<chaals> laura++

we could probably agree on all the pieces of the proposal except the missing alt case

lc: dropping from change proposal a generated attribute explicitly indicating alt unknown addressed

cs: so we could put forth a change proposal about how to deal with missing alt

and another proposal on how to deal with longdesc, labelledby etc.

cmn: adding aria-label

<oedipus> aria-labelledby should be valid ONLY if @alt is present

<oedipus> aria-label value should be SAME as @alt value

<Laura> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#With_Suggested_Text

mr: prefer error instead of warning

errors are more easily noticed

the actual error message should point to WCAG that explains how to correct

ms: certainly can have conformance checkers point to whatever resource we think is best

js: explain difference between error and warning?

ms: conformance checkers are like "lint checkers"

they do static checking of serialized documents

there can be fatal errors, errors, warnings, info

validator.nu uses those classes

underneath; its implementation follows the spec as best it can

<kliehm> @oedipus: Re: aria-label, Google requested that attribute as an substitute of @title without triggering the tooltip, so it's different from @alt

spec errors are error

obsolete but conforming are warnings

also issues discretionary warnings (not in spec), e.g., lack of character encoding spec

<Sean> how slow a train is HTML6 chaals

<oedipus> @kliehm why aria-label instead of aria-describedby for @title content?

tool distinguishes presentation of the classes

<kliehm> @oedipus because they wanted an img attribute, not a referer to another element

<oedipus> @kliehm ok that makes sense for img, but @title is global

the proposal on missing alt would provide a message with a link to a resource

for more guidance

<Zakim> oedipus, you wanted to say that aria-labelledby should be valid ONLY if @alt is present; aria-label value should be SAME as @alt value

gr: aria-labelledby should be valid ONLY if @alt is present; aria-label value should be SAME as @alt value

<Laura> Suggested Text: A conformance checker must report the lack of a text alternative as an error. The img element is only valid when at least one of the following is true:

<Laura> * alt is present (empty or non-empty) OR

<Laura> * @aria-labelledby is present (non-empty only) OR

<oedipus> aria-labelledby should be valid ONLY if @alt is present; aria-label value should be SAME as @alt value

<Laura> * the <img> is located within a <figure> that has a non-empty <figcaption> OR

<Laura> * @role="presentation

lc: the WAI CG proposal included that

jc: not sure sure about that, but apparently accepted it in the WAI CG doc

<Laura> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#With_Suggested_Text

sh: there will come a time that the text alternative is embedded in the image resource itself

don't want to lock that possibility out

e.g., in how conformance checker responds to just the HTML markup

cmn: alt requires contextual understanding of image

the alt in context of its use important

long descriptions can be more generic and embedded in image

but in 10 years of this capability existing, has rarely been taken advantage of

sh: expect it to take over more

cmn: I thought so too 10 years ago

<oedipus> sean, that's the fallicy behind the flickr case -- flickr can extract metadata from an image (resolution, camera type, etc.)

anyway, the issue that image doesn't know its context

<Zakim> Sean, you wanted to say how do we migrate to a world where the alt is a component of the image, and thus src is sufficient

gr: aria-labelledby has same functionality as alt, so @alt is fallback for it

cmn: so in the future could require that must have one of the options

but a warning that for fallback @alt should be present

joc: missed1

cmn: agree

cs: shouldn't be invalid to not have alt

but people want to reduce page size and avoid duplication

not sure the duplication is a good idea

cmn: it is for backwards compatibility

cs: in short term

but not as warnings into the conformance checker going forward

<oedipus> the hope is that 3 years from now ARIA overlays won't be necessary to produce usable, accessible HTML

joc: there could be confusion

<missed a bit>

cs: aria-labelledby useful for icons

<oedipus> command element includes icon and label attributes

remembering that labelledby is visible to all

<Zakim> MichaelC, you wanted to say some images are more context-variable than others

<oedipus> command element def needs to state that use of @icon necessitates @label - not just a11y issue - icons are culturally dependent

<Joshue> +q

<MikeSmith> a?

mc: back to point on context variable images, some more variable than others

joc: use of aria-describedby makes sense

but unsure if suggesting using aria-labelledby will come back to bite us

sf: one use case is to associate an external caption with the figure

<Sean> why is there no aria-textequivalent

<Joshue> -q

mc: let's get back to splitting the change proposal

lc: removed the part about missing alt from the change proposal

<oedipus> plus 1 to LC's revision

Matt was the proponent and he can bring that forward as a separate proposal

<Laura> http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20090126#With_Suggested_Text

<Joshue> Yes, thanks to Laura :-)

mk: need to add aria-label to the above change proposal

js: it says it should be an error

we were moving towards it being a warning

lc: I can't live with it being only a warning

the WAI CG proposal had it that way

<Laura> Structural Integrity of the Language


sf: ultimately we would like an error

but either way a flag is raised

joc: action required either way

we want to improve awareness but allow things to proceed

<oedipus> alt triggering an error has been one of the biggest learning tools in our toolkit

js: this avoids an expected fight otherwise

ms: doesn't absolutely avoid the fight, might not get agreement on warning either

lc: right now in spec it's an error but with lots of loopholes

js: if it disappeared entirely we would fall on our sword over that

ms: spec says it's an error but nothing happens as far as conformance checker

sf: this isn't yet implemented in validator.nu?

ms: not implementable

too much bits of logic

sf: there's an algorithm

ms: yes, that's not implemented

<cyns> +1 Janina on starting with error, since that's what we really want

js: might be best for error to be our position

<oedipus> plus 1 to starting with an error

cmn: does anyone believe it should not be an error?

<one vote>

sf: there are legitimate uses cases in which no alt is available

not that there should be, but that there are

for me, I don't care about conforming, I want to see the alt

if a warning still gets people to add alt, we win

<chaals> [/me undecided about the error being critical, or a bad idea]

ms: an error is an absolute statement that you've done something wrong

warning is that there is probably something wrong, but it might be that you're not

so in case of alt text, when we can't tell for sure that it's a problem the alt text is missing, that might be the more appropriate case

we can communicate this to chairs, and that this was a position we had to "back down to", and that as stated it's something we feel very strongly about

<cyns> I'm very, very uncomfortable with a warning. Very.

<cyns> If src is missing, is it an error or a warning? alt should be the same.

<oedipus> agreed!!!

<Zakim> Sean, you wanted to say should probably say,The img element is only conformant

sh: should use wording like "conformance error" instead of "validity error"

<chaals> [-1 to wheeling and dealing here]

<oedipus> plus 1 to conformance error over warning

<Laura> plus 1 to conformance error over warning

mc: what if we include in the change proposal that @src is also a warning?

so they're both treated equally

<some people soften position, but still objections>

<desire to sleep on all this>

<oedipus> me longdesc for Red_Wedge origins image: http://en.wikipedia.org/wiki/Beat_the_Whites_with_the_Red_Wedge

js: test votes

Are we in favour of @src and @alt being at the same level (both error or both warning)

<Sean> vote for equal: the spec says What an img element represents depends on the src attribute and the alt attribute. So its implied already

<cyns> +1

<2 favour, 4 oppose>

<Laura> vote for equal: t

Can we live with warning?

<Laura> no to warning

<oedipus> minus 1 to warning

<cyns> only if src is also warning

<Sean> if src is warning

8 favour, 4 oppose

<oedipus> missing @alt = conformance error; missing @src = conformance error

<cyns> +1

<Sean> missed the question

Do we support the change proposal, except for the unclosed part about error vs warning?

<all support>

<MikeSmith> [adjourned]

<MikeSmith> very big thanks to Sally Cain and RNIB for hosting

<Laura> bye

trackbot, end meeting

Summary of Action Items

[NEW] ACTION: cooper to organize joint discussion of testing task force and html a11y task force [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action01]
[NEW] ACTION: faulkner to raise bug on ARIA being restricted to a11y [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action04]
[NEW] ACTION: SteveF to raise bug on ARIA being restricted to a11y [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action02]
[NEW] ACTION: Stevef to raise bug on ARIA being restricted to a11y [recorded in http://www.w3.org/2010/04/06-html-a11y-minutes#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/04/07 08:50:41 $