Minutes 2 April 2009

http://www.w3.org/2009/04/02-ua-minutes.html


- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
02 Apr 2009

Present
    sharper, kford, Mark_Hakkinen, JR, allanj, Henny, Harper_Simon
Regrets
    jeanne
Chair
    Jim Allan
Scribe
    allanj, kford

Contents

    * Topics
         1. Consensus on alt
http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal 
         2. Survey Results http://www.w3.org/2002/09/wbs/36791/20090223/ 
         3. WAI-ARIA last call review http://www.w3.org/TR/wai-aria/ 
         4. overflow
http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JanMar/0087.html 
         5. MaxLength and screen readers
    * Summary of Action Items


<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
Consensus on alt
http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeProposal 

<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
Survey Results http://www.w3.org/2002/09/wbs/36791/20090223/ 

--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].
WAI-ARIA last call review http://www.w3.org/TR/wai-aria/

deadline 17 April

JA, MH, KF to draft a proposal by 16 April
overflow http://lists.w3.org/Archives/Public/w3c-wai-ua/2009JanMar/0087.html

<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.
MaxLength and screen readers

<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
Summary of Action Items
[NEW] ACTION: JA ensure success criteria cover this keyboard scrollable
area. [recorded in http://www.w3.org/2009/04/02-ua-minutes.html#action05]
[NEW] ACTION: JA to craft success criteria for 'invalid input' [recorded in
http://www.w3.org/2009/04/02-ua-minutes.html#action06]
[NEW] 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]
[NEW] ACTION: JS update def of enabled element [recorded in
http://www.w3.org/2009/04/02-ua-minutes.html#action03]
[NEW] ACTION: kf summaryize UA position on alt for CG. [recorded in
http://www.w3.org/2009/04/02-ua-minutes.html#action02]
[NEW] ACTION: kford summary UA position on alt for CG. [recorded in
http://www.w3.org/2009/04/02-ua-minutes.html#action01]


Jim Allan, Accessibility Coordinator & Webmaster
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

Received on Thursday, 2 April 2009 18:48:15 UTC