Special meeting on alt in HTML

<jeanne> +1 for Janina chairing

<jeanne> scribe: jeanne

<inserted> ScribeNick: oedipus

JS: third agenda+ are there valid use cases where no @alt is permissable/allowable/correct
... info flow to authoring tools and user agnets
... decisions boil down to these 3

<jeanne> thanks greg r

CS: what level of detail belongs in normative spec - what level of detail moved to informative authoring guide from WAI EO or WCAG

MC: have proposal of sorts - just sent out recently
... posted to CG list

<jeanne> scribenick: oedipus

MC: doesn't have consensus

<MichaelC> proposal is at http://www.w3.org/2009/01/accessibility-spec-roles

JS: address MC's points after - validation, auto-generate, and exceptions can move forward on MC's points

CS: move into authoring

<Loretta> code?

JS: isn't that which is normative and which is informative and what goes into which spec

meant to /me that

JS: basis for moving forward with HTML WG
... additional suggestions?

GV: just scanning MC's post - torn between saying should stop and just go read it -- if agree save a half -hour of discussion and will focus discussion
... are there places where there is "no" alt - is it "no" alt or null "alt" -
... like to find points of consensus
... focus on places where we either disagree or don't know about
... avoid wasting time in violent agreement

JS: think can get through current agenda

Summary of HTML5 and PF work on @alt

JOC: lots of issues and sub-issues within whole topic;
... should @alt be mandatory or optional, and are there allowable situations where no @alt is valid
... could try to use hueristic repair
... metadata attached to image and the fickr case -- can't add @alt -- HTML5 view is "photo is content -- there can be no alt"
... need repair mechanism if decide that there are cases where no @alt are valid

JS: fickr use case answers GV's question -- not talking about "null" but leaving out @alt entirely

JOC: alternate means that isn't author defined

GV: should @alt be mandatory; should UA do error handling and how? when is no @alt appropriate

<Joshue> that sounds about right

GV: 3 issues and sub-issues

CS: flickr one is AU discussion

GJR: flickr case reveals that the line of argument is huge red herring

<Joshue> A sample of our work on the issue we posted on the ESW HTML wiki http://esw.w3.org/topic/HTML/IssueAltAttribute

MC: one question: ecology of specifications -- should @alt be required -- may be many different specs that require; first should thing required or not, and then figure out where it fits; don't want too dogmatic a solution

<Zakim> MichaelC, you wanted to talk about ecology of specifications

JA: UAs without AT don't do any repair -- if image without alt,
... AT doing the work

JS: not just accessibility thing -- for graphicsless browsers

JA: won't work with lynx,

<Joshue> JOC: There may be confusion in the HTML 5 group about AT heuristics vs. UAs like browsers or even web apps and what they should do in situations where there is no alt.

GJR: lynx has several error recovery methods - there are UA error recoveries available; onus should not be on UA or AT, but both

GV: should alt be required for validity? concern i have is saying "we require alt, but there are places where we don't know what to do, we are going to generate placeholders instead of valid alt" -- that is a disservice and leads to more problems
... concerned about whole idea of requiring @alt then deciding too onerus
... is it a stop sign?
... better off not having stop sign if people don't know what to do with them

Should @alt be Required

GJR: yes full stop

GV: required in HTML 4.01 - what is big problem that has arisen since then?

JS: improve stats --- too many failures because of missing alt

GV: more valid pages without required @alt

JS: believe it is that fundamental

GV: concerned about requiring something then winking and saying don't have to
... require in place where can provide exceptions
... this is required part, or isn't -- maybe requiring in HTML is wrong place -- supposed to be a specification doing things that shouldn't in normative or informative especially authoring GLs that have to do with accessibility

JR: don't think HTML5 just pushing ahead because of stats -- broken -- overloaded -- means too many things alt="" could mean ignore or no alt provided -- critical overloading of semantics of attribute, want a proper construct
... to require and have it ambiguous is not a good idea

<Joshue> +1 to Jan

<JR> GR: Question not why HTML5 req alt, but why should HTML5 not re it

<JR> GR: It was req in HTML4

<JR> GR: But now they want to remove, even though they were supposed to be evolving HTML4

<JR> GR: But many HTML5 actions undermine HTML4

<JR> GR: access features

<JR> GR: We know how to deal with alt so we just keep it

<JR> Janina: Stats made

<JR> GR: Yes but contentious....

<Joshue> JOC: The only statistics you can trust are the ones you falsify yourself (sic)

<JR> GR: Those constructs inclyuding alt weren't put there willynilly

<JR> GR: Yes we should evolve better mousetraps but shouldn't throw out what we have till we get there

<JR> GR: HTML5 chose not to follow PF

<JR> GR: Director of W3C approved HTML4 so if HTML5 wants to remove HTML4 features so should have to go back to that

<judy> to JS, GV, MC: I'm now lurking and pingable again

<JR> CS: I agree with GR

<JR> CS: THey seem to want to describe web as is

CS: complete agree with GJR's assessment -- goal for some members of HTML WG to look at statistics to deterimine what is good and what is used; a LOT of HTML behind firewalls -- not checking that; only place i am aware of where the text of content is specified in a markup spec
... doesn't say P has to be at least five sentences; doesn't explain how to use alt, but tries to explain equivalency, does it badly and doesn't belong in an ML; alt should be required but should have strings to key off

<AllanJ> another meeting, back in a bit

GV: alt="" overloaded because means ignore and not available; first time i have heard people use "" for Not Available -- should only be used when graphic is completely ignorable, is covered in WCAG, should have the HTML group describe when appropriate to work

<Joshue> JOC: FWIW the same argument is being used against @summary for complex data tables, a discussion for another day.

GV: question for GJR: been said "should not remove alt because look on web and not being used" that is wrong; but not requiring alt is case of where is it not possible to use alt? what is purpose of picture -- to be a picture -- either required or make legal to put null alt on images or placeholder that doesn't really help blind or mobile user
... question: if have situations where say "really hard" in WCAG give advice -- don't have to put alt on all pages, but if do that, can't say accessible; for HTML required for validity even if has meaningless value for @alt -- could become a widespread practice; is better to say @alt not required for validity but for accessibility

<Joshue> JOC: It looks like they wish for pages that don't have alt attributes to still be considered conformant to HTML 5.

GV: can't give contradictary advice; although alt is how do it today, not clear that always and into future will be using alt
... why required for validity if not best way for validity in the future

<jeanne> something has come up that I have to attend to. Apologies.

<JR> oops CS I ack'd you by accident

MM: behind GJR and CS' comments -- situation of snidley whiplash between those who want to validate everything and those who want accessible solutions; got this into HTML4 for a specific reason -- everyone in line for optinal alt says text is not 100% functional equivalent of image, so can't do it; we KNOW that loss of "fidelity" in case of description
... have a case where HTML WG hasn't proven that they want to improve anything for anyone but themselves and is running us round in circles over even the most triffling things

<Joshue> pretty accurate summary of HTML 5 modus operandi MM

MM: have 1 paragraph that is my biggest sticking point about image analysis hueristics -- they DON'T exist -- exist in way speech recognition did 20 years ago; HTML WG sends us on fool's errands to prove negative; keep going around in circles and we keep having to prove and support our case; trimming from specification and into authoring guide is one way to deal with this

<Joshue> +q

MM: up against a set of bad actors who are not going to listen to reason or experience

<Zakim> MichaelC, you wanted to say we should give HTML WG a solid principle-based counter proposal, rather than just fight to retain what they remove (regardless of their reasons) and to

MC: agree with what Gregg said; i think that rather than worry about how HTML WG processsing issues, rather than worrying about reversing decisions, would like to come to them with concr4ete proposals
... let's do this to address all of our issues -- needs be presented as proposal, not demand
... give them something to chew on; hoping that new WG co-chair sam ruby will help improve inter-group relationships
... there is stuff in the spec that is crazy, but process is crazy as well; shouldn't worry about validity issue -- WCAG did not require it in WCAG2 and took a lot of heat for it and reconsidered many times but decided that shouldn't require validity

JS: difficulties for non-engineering and non-technical issues: burn-out; bruised egos; etc. have had to deal with that hopefully are getting past that

<Zakim> oedipus, you wanted to mention that proposed "role" attribute to do that and provide alt

<JR> GR: First of all...there is doc for this advice...web document design...lachlan hunt's doc

<JR> GR: lots of this in the xtech issue...there is wiki...

<JR> GR: with proposals...like a role attribute to mark things as decorative

<JR> GR: Also trying to come up with media model for HTML5....

<JR> GR: But important to keep mapping back to alt and longdesc since we need a short and long descriptor

<JR> GR: The content model is richer....could accomplish what OBJECT had potential

<JR> GR: But challenge to work with HTML5, my proposals purged

<JR> GR: We need accessibility people to help Lachlin on his document

<JR> GR: Those of us on html5 are getting frustrated...we have done all this work already....

<JR> GR: But dysfunctional process...there is de facto development going on...people are already implementing....

<JR> GR: Not bowing or listening to market demand

<JR> GR: They call it paving the cowpaths

<JR> GR: We shouldn't be paving cowpaths we should be building better mousetraps

<JR> GR: But we need buyin from WAI...eg authoring tool people to work on authoring tool advice in HTML5

JS: chair's priviledge -- halfway through call -- could easily go on for rest of call -- anyone who hasn't yet had a chance to speak?

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

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

<cyns> +1

JS: any requirement that @alt be required for validity doesn't say anything more than saying "ensure headers have appropriate text" "should nest headers appropriately, rather than for appearance" -- this is level of validation -- is it a sentence because there is a period at the end of it -- would that justify keeping @alt required?

GV: problem is as soon as you say "required" and then give advice in other documents, put in something "blah" -- can't require something if going to state there are exceptions

<Joshue> JOC: I guess alt and validation, vs alt an the creation of accessible content are two different things. Maybe they should be explicitly dealt with as two separate things?

GV: not required for validity, but would kick up warning - not invalid, but inaccessible

MC: my proposal addresses that

<Zakim> MichaelC, you wanted to summarize my proposal

<JR> http://www.w3.org/2009/01/accessibility-spec-roles#recommendations

<Joshue> +1 to Michael

MC: my proposal: HTML should provide @alt with semantics same as in HTML4 (no alt decorative, all value for alt must be text intended for user; recommend provide additional mechanisms that provide richer semantics -- would become future solutions, but @alt still there as fallback mechanism because HTML5 has to be backwardsly compatible
... @alt should not be required in HTML5 for validity - explanation in proposal
... use @alt until better solution comes along -- authors should choose one or both and will always advise that do both

<Joshue> JOC: Cynthia is right about the rational for many of the arguments.

<janina> +q

CS: don't think because something is a lot of work shouldn't be requirement for validity; weak arguments advanced -- could easily be corrected with superior authoring techniques as in flickr case; because of that think @alt should be required and i say that as a member of PF and HTML WGs; haven't seen compellling reason as to why should change from HTML4; if have future way of handling equivalency, have engineering proposal for HTML5 or HTML6

or XHTML2!

JOC: are situations where may be no need for @alt, but concern about message -- sends oout message to dev community about importance -- if not required, loses visability and urgency;
... in HTML4 there are mechanisms that provide richer semantics -- OBJECT good example; WCAG2 should be last stop concerning accessibility verbiage in HTML5

FIFTEEN MINUTE WARNING

MM: cows don't like walking on pavement

GJR: nor can you get them to cross a ditch

<Joshue> JOC: I would like to hire daisy as an editor

MM: not asking users or authors if a problem; developer-implementor specific; haven't come up with explanations as to why things were dropped; my participation is grudging, because have to constantly prove to HTML editors and others why we need what we needed in HTML4, which is work we've already done; have problem with argument that "if i can't provide alternate content, then the whole thing falls apart" is a net positive all along; for authoring cases, ATAG1 and

<JR> GR: HTML5 is not respecting full status of WAI recs

<JR> GR: They seem to treat it like nice things fo a small group of people

LGR: just want to put plug in for using text on page rather than alt; ARIA gives possibility

<JR> ack \

GJR notes that he has proposed "for" as universal IDREF in XHTML2 and HTML5

<Joshue> JOC: It may then be best to recommend that some kind of descriptor be mandatory, if not alt?

GV: should not be required because @alt is only one technique: GJR said, need is terse and long descriptors: different ways to do in different MLs -- if can use something in the page, shouldn't need to put in @alt to be valid; it is a critical technique but not the best and only; what should be required are the terse and the long descriptor; new techniques when supported by AT

<Zakim> MichaelC, you wanted to say my rationale that alt isn't required is that it's arguably not part of the minimal semantics required to process the <img> element and to say using

GJR: backwards compatibility a requirement

<JR> GR: We need to keep backwards compatibility...HTML5 charter even says so

<Joshue> JOC: What Greg suggests is fine with me in principle as long as there is some descriptor when needed.

MC: thing Gregg has good rationale for not requiring @alt - can argue that being able to provide text an essential part of being an image -- can come down on either side of that; wary of using validity mechanisms as a club -- backfires on us; another reason to not require alt

<Joshue> JOC: GJR backwards compatibility is also a moveable goalpost.

MC: should separate validity from accessibility
... need to work with WGs to ensure that their content model provides accessibility features; think beyond scope to make required in HTML5, but ok for WAI to require them

<cyns> +1 Matt

MM: disagree completely; alt being mandatory has resulted in alt text -- if had alt as an opt-in attribute, would have less alt out there; reason that mass mailing lists want to be opt-out instead of opt-in -- lack of performance in either case going to have more people doing it; can't stress strongly enough how much alt should be required for validity
... can use aria-labelledby and alt="" and have a valid and accessible page
... is HTML WG going to accomodate ARIA

<Zakim> mattmay, you wanted to say aria-labelledby?

GJR points out that there are 3 minutes and that we are talking specifically about HTML5

JS: return to CS point -- just because it is hard, should mean shouldn't be required; personal opinion is that the fact that alt cookie cutter usage is as harmful as nothing; always going to have high literature and trash - doesn't mean shouldn't have high literature or trash;
... in terms of LRG's proposal, think backwards compatibility an engineering issue; either you use @alt or use an accepable alternative; in terms of validity seems that belongs not in a normative markup language specification, but should be incorporated by normative references to pertinent WAI documents

<Joshue> JOC: Then there is an alt continuum. Maybe its like oxygen. Oxygen should be a mandatory in all circumstances but we have rarified mountain air, and choked city streets but the oxygen should be a requirement.

JS: still no consensus

JB: read minutes; looks like y'all spent a lot of time on process in addition to or rather a solution itself; agree with MM comment about fool's errand to have to prove negative; also think new co-chair will help process of collaboration; not yet consensus on this -- some useful and necessary discussion -- wonder if need to write up a statement or 2 versions of a statement (one pro and one con) and hold off reporting back to HTML WG tomorrow or bring back to CG fo

<MichaelC> has a statement written up, but it doesn't have consensus; would be handy to have another one or two for comparison

<MichaelC> strongly agree with not returning to HTML except "we're still discussing"

JB: try written statements and bring to wider group or to CG; don't think unresolvable

<Joshue> +1 to not engaging with HTML until there is a consensus

JB: alt and validity of HTML has a lot of history; possible for WCAG to reach consensus, but different for HTML; try summary statements and then reconvene and discuss summary statements

<Joshue> sounds good

JS: plus one that

JB: any diagreements?

<Gez> I'll write an opinion on it

<Joshue> I'll help

proposed RESOLUTION: written statements pro and con on @alt as required attribute will be circulated and discussed two weeks from today

<scribe> ACTION: Gez - write opinion piece on @alt as requirement [recorded in http://www.w3.org/2009/01/21-cg-minutes#action01]

<trackbot> noticed an ACTION. Trying to create it.

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

GV: start with list of agreed upon points and points of contention and sort them out
... concrete proposals

GJR: please check the XTech wiki

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

JS: need to decide which list

JB: who doesn't have member access?
... suggest keep discussion on wai-cg list

<Gez> could you add me temporarily?

MC: can read archives, but add to list?

JB: do a mass batch mailing list for it and CC to CG list

GJR: notes 2 proposals: MCooper and Gez Lemon

JS: will meet again in two weeks; will continue discussion in email; bulletted lists and opinions; will ask HTML5 group for month's extension

JB: appreciate discussion -- helpful to read and participate

JS: conflict

note: Cynthia and Gez cannot do 2 weeks

JS: could do it during HTML Caucus Time - 2 weeks from Friday - 6 FEBRUARY 2009

GZ: out that whole week

GV: meet on friday the thirteenth?

<Joshue> /me yup

<JR> can't make it this Friday

MC: this friday too soon

GZ: will make time 2 weeks from today at 2:30 P.M. Eastern US - 4 FEBRUARY 2009

<Joshue> thanks bye

RESOLUTION: written statements pro and con on @alt as required attribute will be circulated and discussed two weeks from today (4 FEBRUARY 2009) at 2:30 P.M./1930h UTC