PF HTML5 Issues Caucus -- 20 Feb 2009

alt in HTML5

<oedipus> Previous: http://www.w3.org/2009/02/18-cg-minutes.html

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

JS: Jan and Gregory have an action item, can you discuss this form where we left off Weds?

JR: Sure

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

GJR: Here is the URI on what we were working on.

GJR: We had 4 cases and drew some conclusions 1) where an image needs alt and the author provides it

<oedipus> The act of populating the value for alt should trigger the insertion of aria-role="image", unless the use case is a composite image, in which case the composite should be contained in a DIV marked with aria-role="image", the alt text defined for the composite image MAY be contained in the first of the composite images, allowing the author to use alt="" on all of the other pieces of the composite image, provided that the first image contained in the composite descr

JR: I just want to say that I have not seen this page, these are your ideas?

GJR: Yes

JS: We should get an overview first.

<oedipus> null alt values MAY be provided ONLY if aria-role="presentation"

GJR: I have three conculsions 1) null alt may be provided only if aria role = presentation.

JR: This is not my idea.

<oedipus> 2. an image with an aria-role="image" MUST be assigned a valid, meaningful, and human-parseable alt text (again, we need to reinforce that alt text and the contents of the LEGEND child element, if FIGURE is used should be identical, with the exception that the LEGEND text can be "rich" (contain markup)

<oedipus> 3. when using IMG, aria-role="image" should be the default value, auto-inserted or manually inserted by the author; if the author changes that value from aria-role="image" to aria-role="presentation", then the author must also provide a meaningful, human-parseable textual equivalent using the alt attribute

GV: I suggest looking at what is here and these are GJRs ideas. We all look at it and comment.
... Or propose something different, air concerns etc

JS: I agree but would also think if Jan and GJR put that together themselves we can look at them later.

GV: I agree, the cases are laid out nicely. Everyone agrees to number one, I daresay. Should both presentation and alt="" both be preseent etc.

GJR: We were looking for a predefined woring we could use based on tools on hand.

<oedipus> when using IMG, aria-role="image" should be the default value, auto-inserted or manually inserted by the author; if the author changes that value from aria-role="image" to aria-role="presentation", then the author must also provide a meaningful, human-parseable textual equivalent using the alt attribute

JS: I would like to give Jan a chance to contextualize.

<oedipus> GJR: yes, one of the 3 must be there

JR: This was an extra piece added later. The original proposal was mind. I was trying to find a way to keep @alt defined. One of the three must be there for validity (@alt, aria value etc). role="presentation" needs to be de-overloaded. What do we do with authoring tools that want to put in labels etc. So there are a couple of ideas here.

JS: I appreciate that. Do we agree on the problem statement?

JR: They are my examples.

GJR: Any image declaration must have either aria role = presentation or aria role = image.

<oedipus> Without the aria-role="presentation" this case should be flagged as a failure/error

GJR: Without these all alt text should be flagged as a failiure.

<oedipus> if aria-role="presentation" is not present, this is invalid markup; validation engines should report this as an error and advise the author to use the aria-role="presentation" to the image, provided that the image is purely decorative and devoid of content; authors should also be advised that they must use aria-role="presentation" to validate their source code. alt="" is allowed ONLY when aria-role="presentation".

GJR: If aria role is not present then the author should be advised as such etc. alt="" should only be allowd when aria role = presentation.

<oedipus> aria-role="image" is present, and no value has been defined for the alt text, that should be flagged as invalid; author should be prompted to provide a programmatically determinable textual equivalent using the alt attribute, whose value should be identical to that provided by the LEGEND element if the IMG is contained in the FIGURE element

GJR: When aria role = image without alt text that should be flagged as an error.

<JR> JR: THis JR's proposal:

<JR> If HTML5 adopts ARIA, HTML5 should do ALL of the following:

<JR> - require the presence of one of the following (@alt,

<JR> @ariaLabelledby, @ariaDescribedby)

<JR> - no longer recommend alt="" for images to be ignored

<JR> - recommend @ariarole="presentation" for images to be ignored

JS: Authoring tools spent a lot of time in this territory.

GJR: Yes, when the author has not provided the information that this is presentational then that is an error.
... We can use aria role = pres and aria role = image as leverage otherwise it can be skipped.

<greggvanderheiden> Allowing ALT="" to be valid for non presentational violates WCAG and AT

<greggvanderheiden> - alt and/or lablelledby [+describedby] is reqiured

<greggvanderheiden> - alt ="" is allowed only for presentation info

<greggvanderheiden> - "presentation" is only allowed for presentation

<greggvanderheiden> - for author can't/won't but wants valid then a value of ALT="AltNeeded" can be used

GV: I am concerned that allowing alt="" to be valid for content that is not presentational as it violates WCAG.

<cyns> can someone put in a link to the cases?

GV: By trying to do case 4 the way you did you mess up case 2.
... So what to do for things where there are content, case 2.

<oedipus> If the author uses <img src="123.jpg">, the authoring tool or rendering engine should detect the missing alt attribute and insert a type="invalid" or type="incomplete" or, more practically, the aria-role="image" to denote that this is visual content which MUST have a textual alternative provided for it

GV: For case 4, alt needed can be used.
... Describes various cases.
... Discusses repair strategies, where they are an are not needed.

JS: Cyntia?

<Zakim> Stevef, you wanted to say haven't the UAA WG been discussing this?

SF: Just to say my understanding that the UAWG is discussing this also.

<oedipus> my scenario, the aria-role provides the programmatic hook to determine if a textual alternative (alt, describedby, and labelledby) is mandatory or

SF: Should we get some feedback from them.

GJR: Jan is here.

<oedipus> steven, markH is a GREAT resource

CS: Wonders about no alt.
... Am worried about removing validation requirements.

GV: Alt needed would require alt for validation.
... Alt needed would be how you validate without concrete values.
... Use alt="" if it should be ignored
... This is not a second attribute but a value of alt.

<oedipus> GV: use alt="value-needed" to flag missing alt

JR: Missed GJRs mail yesterday. The US view is we just need to get the information unambiguously.
... So we need to describe the various possibilitites.
... I agree with GV that the last case is an accessiblity error.

<oedipus> Without the aria-role="presentation" this case should be flagged as a failure/error -- the author hasn't provided the requisite information that declaratively marks the image as presentational, so the empty value for alt should be flagged as an error

JR: My proposal would be that a UA that cared could do whatever repair technique that worked.
... Already alt="" is used by many UAs for various things.

<Zakim> oedipus, you wanted to say that the reason i predicated things on aria-role="presentation" and aria-role="image" so that a textual alternative is provided (alt, or labelledby)

GJR: explains reasoning.
... If useing aria role = image you have to use on of the ?? outlined. The example in 4 is wrong.

GV: A WCAG error.

JR: All those cases should be valid HTML, case 3 & 4 is a WCAG error

GJR: The rendering engine could detect the missing attribute and insert type = incomplete.
... Rather than introduce specifics, I would like to have the concept of declaring this content as presentational, otherwise you must declare the value.
... The user should be able to describe these images if they want.

JR: Don't see the point in labelling images as images if we know they are presentational

GJR: I think given the tools in HTML 5 now, I like using presentation of images as a filter.

<JR> Correction: JR: If somethign can either be an image or a presentation, then only label for one is needed and if it is not labelled presentation it is an image by process of elimination

GV: We need forwards and backwards compatibility as well as flexibility.
... Using ARIA we may find we want to move beyond alt.
... We have to look for backw comp we cannot redefine what alt="" means.

<oedipus> alt="" is allowed ONLY when aria-role="presentation"

GV: It is ingrained.
... There is no concensus on what it means in every instance.

<oedipus> i don't think it wise to have authoring tools spit out alt="" when author fails to provide -- that is a failure of the authoring tool and the author

GV: If we want a valid way to put something in an alt, that states 'I don't care' we need to put something easy to identify in there.
... alt needed does this nicely.
... One use case is where one group doesn't know what to do, etc, should be able to prodcue valid code.

<oedipus> michaelC, i am in VIOLENT agreement with you

GV: Alt = different is easy to detect, backwards compatible etc
... There is inconstiency across iterations of the HTML spec which is problematic.

<Stevef> +1 to MichaelC not token

JS: It seems we are moving closer to a resolution?
... We seem to have agreed that we will find a way to keep validity as part of the process.

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

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

JS: Keeping alternate text as part of the process.
... We should make the cases unambiguous.

<Gez> +1 to MichaelC, as will result in namespace pollution. If someone starts a company called repair-needed (or whatever the token is), every time AT parses the valid alt text, it will try to repair it

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

CS: The authoring tool could put alt = role or pres etc on all images, am not sure if the proposal satisfies this?
... Where the author does not know what to do, guidelines etc could provide advice a la WCAG.

<Zakim> cyns, you wanted to ask what prevents naughty authoring tools from slamming role=presentation on everything in the same way that they now slam on alt=""?

JR: To answer cyns question about inserted role= pres etc.
... They wont to this because they are more concerned with validity that ally
... Putting aria role = pres would be a fib

<oedipus> we can't stop people from lying - you can't fix stupid

JR: We cannot change what @alt values mean? Maybe we need to change this.

noalt as an attribue would be prefered.

<Zakim> MichaelC, you wanted to say I oppose defining a special token for alt, which takes an open string value. "alt needed" might be something authors use to manage their process, but it

JR: To do this someone needs to co-operate. Many don't care. Let them just add alt="" to do the same thing. Other soltuion may not fly.

<Zakim> oedipus, you wanted to say very strongly opposed to providing "validity" through alt key-words -- alt MUST be retained for human consumption and another attribute MUST be available

MC: Am worried we are mixing issues like validity and usefulness etc. We need to focus on usefulnee here, validity can be done in HTML. To progress the issue. Alt is a string value we should not provide a token for it, (notes from IRC).

GJR: I agree with MC and Steve that using keywords and token strings in @alt is very bad.
... If we are thinking of backwards compat alt will have to be the mechanism.
... Using labelled by etc, where does that leave older UAs?

SF: We have alt provided, or aria lab/desc. This gets over the flickr use case. As developers will know the image provides a way to provide a descriptor at some point.
... Relationships can be set up, not asking for text but for a defined relationship.

GV: Regarding MCs comment. These are all at the table. We need a solution that covers all of these.

<janina> +1 to gv

<oedipus> scribe: Joshue

GV: We need a solution everyone can live with.

<oedipus> plus 1 that all 3 are intertwined

GV: This may not be easy.

<oedipus> ScribeNick: Joshue

GV: Its a conundrum.
... Some are taking of not tokenising alt needed. 1)This feels bad, though it works 2) There could be a new value where alt is needed not as a token but as an element.
... If we did the latter we could be saying alt = something (a text alternative)
... You must have one of the 4 discussed mechanisms.
... Why would user put in alt needed? They wouldn't but the tools would be designed to facilitate the valid code. Even if they did nothing at all. Why? Because its the quickest way to validity.
... Otherwise its alt="" where you cannot tell what that means.
... This could give us somthing everyone could live with by seperating them out. What about Back compat? This works as it doesn't have alt="". They would trigger repair.

JS: Time check.

<Zakim> MichaelC, you wanted to say some validity approaches we're discussing go beyond traditional "dumb validity" and are more evaluation oriented; I don't know if the HTML WG is

MC: As a response, trying to do them all at once makes this very hard as there is not a unified frame of reference that make progress hard.
... Also validity approaches go beyond traditional validity. Don't know if they will support contextual validity.

<Zakim> oedipus, you wanted to say that type="invalid" where alt is not provided is a cleaner solution

JOC: I didn't know there was such a thing as contextual validity. Like it!

GJR: I think conditional validity is unavoidable.
... If the user does role=presentation that should allow them to use alt="".

<Zakim> JR, you wanted to reiterate that uncooperative people unlikely to go the extra mile...we'll need accessibility-friendly authors to go the extra mile

GJR: We need conditional validity, its needed for progress.

JR: The reqs in my proposal just has alt="" or labelled by /described by etc, thats it.
... The easiest thing for a tool to do with alt = needed will visually trigger popups in IE.

GJR: I would be more flumuxed by alt needed.

JR: Suggests a yes alt.

<oedipus> a conscientious author who desires to provide both human-parseable and machine-processable information about the IMG needs a means of communicating a textual equivalent to the user as well as a means of providing machine-parsable information.

CS: Putting in a user understandible string to state the situation (image without alt etc) could be useful.

JS: We are nearly done but no resolution.

<oedipus> GJR: notes that the examples in the page we examined need to have the alternative scenarios (labelledby)

GV: If we go to the bottom of the wiki page, there is link to new page, alternate proposal. Various cases are there. Any of those are valid,

JS: So you have a proposal?

GV: Yes, on the wiki.

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

<oedipus> http://esw.w3.org/topic/AlternateProposal

<cyns> need to run

JS: We are supporting validating. But need to work out how we handle both corrent and incorrect use and the rest falls into place.
... Does anyone disagree with that?
... The problem is the mechanism.

JR: I agree the problem is the overloading of alt="".

GV: We are exploring different approaches.
... Everying seems to collapse, not requiring validity, or nor giving authors a way of breakingn WCAG.
... One of the arguments for having mandatory alt is that it brings it to users attention.

JS: How can we move forward.

GV: I want to say we should try to adopt this attribute to disambiguate.

<oedipus> http://esw.w3.org/topic/AlternateProposal

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

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

GV: GJR did come up with another approach, it was flawed but we need others if possible

<oedipus> plus 1 to next friday

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

<inserted> ScribeNick: oedipus

JR: alt="" has to lose "ignore this" and "i just don't care"
... my proposal says if want user to ignore, use aria-role="presentation"

GV: problem is no backwards compatibility
... don't care about alt="" - not appropriate -- move inappropriate behavior to new attribute

JR: dealing with people who don't care

GJR: fail to understand why an author would use a noalt or altneeded attribute

GV: don't want to be valid unless have valid alt, that's never going to happen
... what can we do next to foster something constructive
... setting requirement for those who don't believe in alt is important
... "noalt" rather than "altneeded" would be more welcome

JS: disambiguate in code the improper use

<inserted> ScribeNick: Joshue

GJR: The link to your proposal is on my page.
... I submitted the Role attribute proposal to PF in august 2008 when trying to get the curly braces verbiage out of the spec.

<inserted> ScribeNick: oedipus

GV: challange to use boolean logic to mean things is completely foreign to any author --
... good way to find answers, but not what i would like as a proposal; advantage of GJR's proposal is doesn't add new attribute
... move good behaviors to ARIA and bad behaviors to code provides a solution, but raised backwards compatibility issues

JS: can't ignore backwards compatibility

GV: think AT will quickly migrate to ARIA and role support
... if can do that, would be less worried; ARIA is very elegant; need to do what we can to get people migrated to it
... new content in old attributes not good idea
... what is best proposal going forward

http://esw.w3.org/topic/AlternateProposal

http://esw.w3.org/topic/PF/XTech/HTML5/RoleAttribute

http://esw.w3.org/topic/PF/XTech/HTML5/Caucus

JR: will post my proposal to wiki
... short and sweet

GV: pull alt="" from case 2 to case 4

JR: can be deprecated to signal "ignore" -- rampant abuse of alt in past

GV: is it everyone's perception that alt="" not synonomous with hiding irrelevant content?

JR: too much misuse of alt="" just spit out by authoring tool

GV: should a user not treat alt="" as something skippable
... if alt="" is 10 to 1 used incorrectly; suggest switch over to JR's plan and just abandon alt="", but then, mandating alt="" means a lot of content needs to be changed

JR: agree - if used correctly 99% of the time, would support
... if alt="" is rampantly abused and cannot be trusted, no backwards compatibility issue

GV: one more piece - tipping point is closer to 60-40 not 90-100
... pressure to make web site accessible; legal documents that require people to use alt="" on IMG; change rules, means legal documents requiring people to do the wrong thing; not good to abandon it and undercut credibility of legal standards
... don't think should change meaning of alt="" as an acceptable technique
... if do a double-back, all defendants need to say "we can't conform to rules that constantly change"

GJR: but rules for HTML4x and XHTML1.0 content don't change

<Stevef> stevef thinks its madness to change meaning of alt=""

JR: HTML language - if they decided to change element from IMG to IMAGE that would break things

GV: no case law that says have to do that -- just says "provide textual alternative/equivalent"

GJR agrees with steve

GV: need to provide continuity to current accessibility initiatives

JR: my mind not closed to the "noalt" attribute -- psychology of it is a bit backwards, but can see with legal reasons why may be best thing

GV: "noalt" indistiguishable from alt missing -- has to be something that says needs an alt, none provided
... cases don't say what to do on HTML4 pages, but just "on web pages"

GJR: i'm thinking in terms of what is needed for HTML5, which is what we were asked to provide

GV: if don't put in alt, noalt inserted
... may be too easy to fudge with noalt

ADJOURN

Next Meeting - Friday, 27 February 2009 at 1500UTC

- DRAFT -

PF HTML5 Issues Caucus

20 Feb 2009

Attendees

Contents

alt in HTML5

Summary of Action Items

Scribe.perl diagnostic output