PF HTML Issues Caucus -- 27 Feb 2009

<janina> Meeting: PF/HTML_Caucus telecon

<janina> Chair: Janina_Sajka

<janina> agenda: this

<Ben> hi all, sorry to be late - what is the code?

<Ben> thx

<scribe> scribe: Gregory_Rosmaita

<scribe> ScribeNick: oedipus

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

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

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

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

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

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

Agenda Review

JS: most of hour will be dedicated to how to handle markup where the user intentionally ignored prompting and did not bother to put in an alt value; therefore, what does the authoring tool that cares put in for alt?
... alt should have an appropriate string
... if HTML5 incorporates ARIA can use describedby
... couple of proposals on table -- GV and JR proposal and GJR proposal
... need to decide which tack to take -- need resolution, but see how discussion goes

GreggV and Jan Proposal

GV: 1 preamble comment: never turn in a proposal you are never going to get; write it so that you will get it;
... shouldn't be coming out of here with something we agree on, but doesn't have chance of adaptation; need to do something others can live with; if don't, need to have compelling reason and a fallback position
... 2 proposals:
... both start with HTML requires a terse descriptor and that it tries to not get into accessibility too far
... one approach: anything a person cannot validly label as presentational needs to have an alt value assigned for it; if people don't add alt - autoinsert "altneeded" - reasons: page creator may not know about alt; most authors interested in validity not conformance
... validity doesn't get into content - gets into syntax; my proposal allows both
... second approach - no altneeded; if do not know what alt is, then put something in that is a placeholder, but in HTML5 doc says "this would yield valid HTML5, but would not meet spirit of alt or WCAG 2.0; valid for syntax; currently HTML5 implies that there are specific things to do with alt as HTML5-appropriate thing to do
... talking to Jan, he felt that didn't like second approach -- did not give tools easy way to find those things, unless tokenize them, which we don't want to do
... tokenizing - may not be easy to discover
... needs rules

JS: confused: first option is "altneeded", what is 2nd?

GV: what currently propose in HTML5 - in bulk situations, put some "bulk" tag in (should be unique), but HTML5 spec says specifically though this will validate, this is a misuse of the tag -- valid, but not conforming
... would not meet wcag 2.0
... state in standards that this practice will violate wcag 2.0
... don't want HTML5 to counter what is contained and advised in WCAG 2.0

JS: concerned that we are conflating a couple of things here; want to unravel skein
... focus on strings that are automatically provided -- do not meet accessibility needs; aren't those quantitative judgements when value provided for alt; what do we do when nothing is done -- if not "altneeded", what happens

GV: do have failure for placeholder text; not text alternative (can stand in for image); has to have same purpose -- "photo1" "photo2" strings are meaningless; does the image need alt at all?
... auto-generation: could have PNG with data in PNG, tool could yank out meta-data and substitute for PNG
... concern: what is put in alt fails WCAG because matches a failure in WCAG to provide alternate and same functionality
... part of problem: 90% of web not valid is the claim, but number of photo aggregator sites relatively small
... treating alt as reason pages are invalid due to a class of pages, this is a problem; double fallicy
... need to address means so that not every page has to follow same rules in cookie cutter fashion
... second proposal same as extant in HTML5, with caveat that one is creating valid content, but content that fails for conformance and WCAG

GJR Proposal

GJR: when an author declares an image, the tool auto-inserts either role="image" or type="image"
... when role="image" or type="image" then ALT is required
... only case alt is not required is when the image declaration is CLEARLY marked as prsentational using either the role or type attribute

GV: if write by hand, put in IMG without role or type is alt required?
... if put in alt="photo1" that is alt

GJR: the only circumstances in which alt="" would be allowed is when the author or authoring tool explicitly changes the role or type value from "image" to "presentation"

GV: if alt text is "photo1"

<cyns> is anyone else having the sound cut out?

GJR: bit of a red herring we know that we can only give advice to authors on proper use of alt, we don't have policing powers, but we do have opportunity to ban tokens

JS: HTML5 spec - validation; WCAG conformance

CS: my original question was to ask if GJR on table;

<Zakim> cyns, you wanted to ask if we've decided against something like <img type="photo"/>

CS: some qualms about WCAG value wording; like GJR's proposal -- works better with tools at hand;
... attribute that describes what kind of image it is?

GJR: i purposefully left room for that - by proposing both role and type; if we make type generic, then we can pre-define roles such as "button" "link" etc.

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

CS: don't like using role for photo - to me smacks of user interface role; like means of saying this is photo, this is a screenshot; author doesn't know what alt is, can still give info about image that AT or UA could use to help user in absence of alt, while not messing with meaning of alt
... need role (aria-role) and type (what kind of image it is)

GV: trying to examine this, the third proposal - concern we had in WCAG - already requires alt, they want conformance/validity up; if alt is required, they want to be able to say there is something easily auto-inserted otherwise alt won't be used and page will not validate
... need to work with HTML5 to find a way for page to be valid, but spec to say "this will pass a validator, but is not garunteed to conform to spec" -- tokens can be recognized to provide function; meets the syntax of the law, but not the semantics of the law
... can do all sorts of things that aren't according to spec that validator will validate; if goal is to have pages test valid, concern and problem with our proposals is that if someone puts "suff" in alt, will pass both proposal 2 and 3; no way to test but for human to review every one; altneeded approach is a way that enables author to test valid, but leaves a flag behind that indicates something needs to be semantically added to IMG to meet spirit of HTML5 and
... altneeded tells author - go back and fill in alt values; syntax is correct, have to fill in content (proposal 1)
... second and third - state alt required, but need to say if put anything in alt that is not a true alternate text that gives same function as image, would test valid, but would not meet the HTML5 spec or WCAG 2.0
... validity and following the spec is not the same; validator validating syntax, not spec itself

JS: seems to me that really don't want HTML5 giving guidance on use of alt text -- when w3c speaks of accessibility, should reference WAI documents; HTML5 should reference WCAG to state what is a valid alternative representation; want them to follow w3c process, where issue has been addressed by experts in field;
... can never completely get to something that can disambiguate pure syntax from semantics; probably always way to insert garbage; storyline that moves forward is alt="needed" to disambiguate cases of alt="" being used know, and keep that PURELY presentational; support properly provided strings, but also value in marker that says "this is needed here"
... having that clearly in markup would be very useful
... if try to put into "role" or "type" or logic how to attribute image, not as clean -- not sure progress over HTML4x

GV: 2 things: 1) refer to WCAG for proper guidance on providing alt - there are several ways of doing text alternatives that are valid, name them, and then "see WCAG 2.0 for an explanation of what a textual equivalent is and what is presentational
... concern: will feel compelled to go beyond that and claim when have flickr type interface need something; even if abuse alt tag, will still validate, but HTML5 shouldn't suggest the abuse
... if could do that, role="image" and others can be done;
... skirt the issue of placeholder text
... if use placeholder text, would still validate, but not satisfy WCAG; shouldn't say placeholder text is ok
... if require alt, placeholder has to be in spec; killer for us; why need alt="needed" and not an abuse of tag

JS: seems to me from negotiating PoV, we would cede a decade of W3C process which states that accessibility is the balliwick of WAI
... not up to individual WG to do that on its own -- WAI created specifically to bring in expertise so that accessibility and interoperability built-into w3c specs; don't want WGs coming up with accessiblity claims without consultation with WAI;

<Joshue> +1 to Janina

<cyns> +1 to Janina

JS: not so troubled by HTML WG reaction as by what is end point? no reason to change our responsibility; HTML WG requirement is an alt="needed" -- improve textual equivalents thorugh ARIA -- allows us to do additional enchancements to alt, but don't need automated way to put in placeholder text to achive validity;

GV: what is it exactly you are proposing JS?
... HTML5 WG may say in response to "refer to WCAG 2.0 for textual alternative" - may counter that alt isn't just for accessibility

JS: saying same thing on "summary" for TABLE -- have mechanisms - if want to use curb-cuts for bikes and scooters, see what works then let us build upon the mechanism and improve it

GV: want to talk about alt text -- can't say WAI has exclusive last word on what constitutes alt text because not just about accessibility
... what if put in "for appropriate uses of alt to meet the needs of people with a disability, consult WCAG 2.0" -- could then give bad advice for million other things, but if want to use appropriately for accessibility refer to WCAG 2.0

GJR: very very very opposed to this line of reasoning

GV: all sorts of valid uses for alt other than accessibility; if have curb-cut guideline saying "curb cut only needs to be 18 inches wide to work for bikes, luggage, and skateboards -- see WCAG on accomodation of wheelchairs
... even if doesn't work for wheelchairs, still important
... seems to me that a reference to WCAG would help ensure that there is a solid cross reference with WCAG

JS: will become less interesting to fight this battle\

<Joshue> I think WCAG should just concern itself with accessiblity.

<cyns> I have a hard stop in 3 minutes. can I jump que?

JS: not get too entangled with other uses

<Zakim> oedipus, you wanted to say i am very opposed to the model of "accessibility and only accessibility is the WAI's purview"

<Joshue> Issues of Universality and multi purposing content for other things like SEO etc should not dilute good accessibility.

<greggvanderheiden> PROPOSAL: HTML5 states that "there are several ways of providing text alternatives (ALT, LabelledBy, DescribedBy, etc). One of these is required for Validity. For guidance as to what constitutes a text alternative for the purpose of disability access see WCAG 2.0. PROPOSAL part 2: That use of role = presentation be taken from ARIA Spec . The ALT ="" be the same as "presentation"

next meeting is Wednesday at 1930h UTC

<cyns> Alt is always for image replacement, summary is a little squshier

<Joshue> Especially, good existing methods/elements/attributes IMO

GV: would like people to consider proposal dropped into IRC -- clearly state use of alt for accessibility covered by WCAG; may meet our essential needs and something they can live with

JS: has to be an important part of what we say to them

ADJOURN

- DRAFT -

PF HTML Issues Caucus

27 Feb 2009

Attendees

Contents

Agenda Review

GreggV and Jan Proposal

GJR Proposal

Summary of Action Items

Scribe.perl diagnostic output