See also: IRC log
<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
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
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: 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
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/over HTML5/over HTML4x/ Succeeded: s/sayh to them/say to them/ Found Scribe: Gregory_Rosmaita Found ScribeNick: oedipus Default Present: Janina, Gregory_Rosmaita, Laura_Carlson, Matt, Gez_Lemon, Ben_Caldwell, Cynthia_Shelly, Michael_Cooper Present: Janina Gregory_Rosmaita Laura_Carlson Matt Gez_Lemon Ben_Caldwell Cynthia_Shelly Michael_Cooper Joshue_O_Connor Gregg_V Regrets: Steven_Faulkner Agenda: http://lists.w3.org/Archives/Member/w3c-wai-pf/2009JanMar/0477.html Got date from IRC log name: 27 Feb 2009 Guessing minutes URL: http://www.w3.org/2009/02/27-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]