See also: IRC log
<oedipus> Previous: http://www.w3.org/2009/02/18-cg-minutes.html
JS: Jan and Gregory have an action item, can you discuss this form where we left off Weds?
GJR: Here is the URI on what we were working on.
<oedipus> <img src="123.jpg" alt="Photo of my granny">
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?
<oedipus> <img src="123.jpg" ariarole="presentation" alt="">
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
... 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
... Describes various cases.
... Discusses repair strategies, where they are an are not needed.
<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
... 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
... 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
... 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 =
... 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.
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
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
... 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
... 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
... 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.
<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
... 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.
GV: GJR did come up with another approach, it was flawed but we need others if possible
<oedipus> plus 1 to next friday
<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
... 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
JR: will post my proposal to
... 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
... 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
... may be too easy to fudge with noalt
Next Meeting - Friday, 27 February 2009 at 1500UTC
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Exaplins/explains/ Succeeded: s/JR: Alt needed the attribute/noalt as an attribue/ Succeeded: s/soltion/solution/ Succeeded: s/GJR/GV/ Succeeded: i/JR: alt=/ScribeNick: oedipus Succeeded: i/Previous: /TOPIC: alt in HTML5 Succeeded: i/GJR: The link/ScribeNick: Joshue Succeeded: i/GV: challange/ScribeNick: oedipus Succeeded: s/I submitted this a while ago/I submitted the Role attribute proposal to PF in august 2008/ Found Scribe: Joshue Inferring ScribeNick: Joshue Found ScribeNick: Joshue Found ScribeNick: oedipus Found ScribeNick: Joshue Found ScribeNick: oedipus ScribeNicks: Joshue, oedipus Present: Gregg_V Janina_Sajka Jan_Richards Cynthia_Shelly Joshue_O_Connor Steve_Faulkner Gez_Lemon Gregory_Rosmaita Michael_Cooper Regrets: Laura_Carlson Agenda: http://lists.w3.org/Archives/Member/w3c-wai-pf/2009JanMar/0346.html Got date from IRC log name: 20 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/20-pf-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]