See also: IRC log
<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?
<yup>
<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
http://www.w3.org/2009/06/Text-Alternatives-in-HTML5
<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
<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.
+q
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
<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
<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
<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
<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
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
<oedipus> FIFTEEN MINUTES TO TOP OF HOUR
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