See also: IRC log
<trackbot> Date: 02 April 2009
<KFord> Chair: Jim_Allan
<KFord> Correcting survey link., http://www.w3.org/2002/09/wbs/36791/20090331/
<AllanJ> scribe: allanj
<KFord> zakim list agenda
<JR> Proposal:
1. IMG is only valid when @alt is present (empty or non-empty)
2. For cases in which it is appropriate for user agents to ignore the presence of the image (e.g., when they are used for decoration, formatting, or are invisible):
* alt="" MUST be present
* @role="presentation" SHOULD be present
3. alt="" WITHOUT an accompanying role="presentation" triggers a non-critical validator warning recommending use of role="presentation" (but @alt="" remains technically valid)
KF: choices for response.
JR: sent responses, but not on survey results
MH: same
KF: same
<JR> JR: I appreciate the simplicity and backwards compatibility of this proposal. My only concern is about the affect it will have on adoption of ARIA-labelledby.
JR: if we always require @alt why
would you use @labeledby
... what is its future
KF: do we want to risk backwards compatibiility.
JR: compatibility is a
commendable goal
... question of simplicity. @alt is one of three options
KF: past is use @alt
JR: perhaps @labeledby is not
needed for images, but necessary for other things
... good thing about @labeledby, can specify (link) description
to image
<mhakkinen> I would still favor recommending an @role value that would unambiguously
<mhakkinen> indicate that the image is indeed content, and that either alt text is
<mhakkinen> present, or the AT will use aria, content in the figure markup, or other
<mhakkinen> techniques to find alt text.
<mhakkinen> From last week I can understand the rationale for not making role required
<mhakkinen> ... don't break existing code. But, aren't enough other things changing in
<mhakkinen> HTML5 to make backward compatibility concerns moot, and aren't there ways
<mhakkinen> to address this re validators?
<mhakkinen> The proposed approach continues to allow for ambiguity, without enforcing
<mhakkinen> any real change.
<mhakkinen> Further, recommending @role=presentation may become the easy way for an
<mhakkinen> author to not deal with the problem, removing an image from the initial
<mhakkinen> view of the UA/AT (a whole other topic).
<mhakkinen> The present proposal doesn't really fix anything if authors don't follow
<mhakkinen> these rules, and without requirement, many won't.
<mhakkinen> One possible approach, using the non-required model:
<mhakkinen> "Alt="" WITHOUT an accompanying role="image???" or role="presentation" or
<mhakkinen> described-by triggers a non-critical validator warning recommending use of
<mhakkinen> use non-blank alt text or aria described-by."
MH: still ambiguity. concerned
about @role
... explicitly requires @role. what is the intent of the image.
using @role removes some ambiguity.
SH: neutral. can see both points. want simple. not so concerned about backward compatibility
<sharper> JA: Like marks idea of requiring the role
JR: like original ALT proposal
http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal
... requiring @role would break all pre-HTML5 pages.
... spacer is an image, so is @role image is confusing
MH: right. @role=presentation is not meaningful. suggest- decorative or non-informational
KF: send comments
... change definition, with @role, language is too
complicated
... technology moves forward. can live with @labeledby. browser
of today would get gibberish if I am not using the most upto
date browser. because it doesn't recognize @labeledby
JR: how long do we wait for AT to
catch up.
... @labeledby goes in the DOM. descriptions should be
there.
KF: AT do DOM parsing. accessibility architecture provides other information
JR: go with aria, and what is the timeline
KF: can live with current proposal
MH: image with @labeledby, any limit on what it can reference
JR: if image was graph, could link to a table.
MH: how do we validate that the referenced information has any value.
JR: no easier to validate an @alt.
MH: right, could be better or worse
JR: like the 'in plain view' easier for author to update, @alt is hidden
MH: could move it off screen
JR: should be able to do that. talking about 'describedby
KF: any consensus?
JR: CG proposal is too complicated
+1 all around
JR: some short text is required - @alt or @labeledby
does UA just have to process the information
JR: more than that, must have the technical and accessibility considerations
KF: must have short text. two
ways @alt, @labeledby
... -1 @alt must be required
<JR> KF: I'm coming down on @alt is the required attribute
MH: +1 kelly
... what about mobile browsers, easier to process @alt, or
query DOM to find displayable text
... mobile browser may not support ARIA, then how is
information presented
JR: chart example. short text - some caption text, describedby - longer description
MH: google search look at not just @alt, but also need to look at @labeledby
JR: Ok with HTML proposal
JA: +1 to JR
<JR> SH: +1 to kelly
KF: response to ALTwg
... too complicated
... point back notes
<KFord> ACTION: kford summary UA position on alt for CG. [recorded in http://www.w3.org/2009/04/02-ua-minutes.html#action01]
<trackbot> Sorry, couldn't find user - kford
<KFord> ACTION: kf summaryize UA position on alt for CG. [recorded in http://www.w3.org/2009/04/02-ua-minutes.html#action02]
<trackbot> Created ACTION-166 - Summaryize UA position on alt for CG. [on Kelly Ford - due 2009-04-09].
KF: group split on @alt & @labeledby
--enabled element
Resolved: enabled element, disabled element
An element with associated behaviors that can be activated through the user interface or through an API. The set of elements that a user agent enables is generally derived from, but is not limited to, the set of interactive elements defined by implemented markup languages. A disabled element is a potentially enabled element, that is not currently available for activation (e.g., a "grayed...
scribe: out" menu item)
<scribe> ACTION: JS update def of enabled element [recorded in http://www.w3.org/2009/04/02-ua-minutes.html#action03]
<trackbot> Created ACTION-167 - Update def of enabled element [on Jeanne Spellman - due 2009-04-09].
<scribe> ACTION: JS check version of 'equivalent alternative' this should have been dealt with already [recorded in http://www.w3.org/2009/04/02-ua-minutes.html#action04]
<trackbot> Created ACTION-168 - Check version of 'equivalent alternative' this should have been dealt with already [on Jeanne Spellman - due 2009-04-09].
deadline 17 April
JA, MH, KF to draft a proposal by 16 April
<KFord> Scribe: kford
This has to do with CSS where an author sets a div with an overflow descriptor. You can get scroll bars but it doesn't get keyboard focus.
JA: I thought we had this covered
under keyboard operation.
... What does the group think? Is this covered, do we need a
technique or what?
... In short is this covered under 4.1?
... This doesn't normally get keyboard focus.
... This is kind of like the tooltip situation.
KF: My impression is that this is an example of many cases we could come up with.
JR: I think we also want to throw this under focus as well. Success criteria cover this. Need to cover keyboard action for scrollable areas.
JA: Might this fall under enabled element but is this stretching it?
<scribe> ACTION: JA ensure success criteria cover this keyboard scrollable area. [recorded in http://www.w3.org/2009/04/02-ua-minutes.html#action05]
<trackbot> Created ACTION-169 - Ensure success criteria cover this keyboard scrollable area. [on Jim Allan - due 2009-04-09].
JR: Jim, check 3.11 where we have some of this already.
JA: Could this be another little viewport?
JR: Exactly.
<AllanJ> automatically reject input
<AllanJ> KF: UA should ding or something, some indication of invalid input
<AllanJ> MH: also scripting issues where max length is reached it jumps to next field
<AllanJ> ACTION: JA to craft success criteria for 'invalid input' [recorded in http://www.w3.org/2009/04/02-ua-minutes.html#action06]
<trackbot> Created ACTION-170 - Craft success criteria for 'invalid input' [on Jim Allan - due 2009-04-09].
<AllanJ> any general case beyond max length
<AllanJ> MH: anything in HTML5 about content types
<AllanJ> JA: what about 'required'
<AllanJ> MH: input types, date, time, range, uri, password, required
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: allanj Inferring ScribeNick: AllanJ Found Scribe: kford Inferring ScribeNick: KFord Scribes: allanj, kford ScribeNicks: AllanJ, KFord Default Present: sharper, kford, Mark_Hakkinen, JR, allanj, Henny, +0203091aaaa Present: sharper kford Mark_Hakkinen JR allanj Henny +0203091aaaa Harper_Simon Regrets: jeanne Found Date: 02 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/02-ua-minutes.html People with action items: ja js kf kford[End of scribe.perl diagnostic output]