Minutes: 20 Jan 2011 User Agent Accessibility Guidelines Working Group

see: http://www.w3.org/2011/01/20-ua-minutes.html

User Agent Accessibility Guidelines Working Group Teleconference
20 Jan 2011

See also: IRC log http://www.w3.org/2011/01/20-ua-irc
Attendees

Present
    Jeanne, Greg, KimPatch, Jim_Allan, sharper, Jan, MarkH
Regrets
    kellyFord, PHLauke
Chair
    JimAllan, KellyFord
Scribe
    Greg

Contents

    * Topics
         1. liaison to HCG working group
    * Summary of Action Items

<trackbot> Date: 20 January 2011

<jeanne> simon, are you joining us?
liaison to HCG working group

<mhakkinen> Mark is on irc... will be calling in shortly

<JAllan> Meetings for the next 2 weeks to start 2 hours earlier and
will run 11-3 eastern, pending bridge availability

<jeanne> http://www.w3.org/2010/12/audio-wg-charter.html

Janina Sajka, the head of PF is interested in audio accessibility. In
the coordination group meeting yesterday she asked UA to participate
in the new Audio Working Group.

Their goal is to create APIs for audio in the browser. What WAI would
like to do it position them to use UAAG among their requirements.

They'd like UAWG to have a liaison to the AWG.

The meeting schedule has not been established yet.

Mark would like to participate, IF it meets at a tie that works for him.

Doug Schepers will be the W3 team contact for AWG, and so the one to
talk to about their schedule.

AWG goals include giving the browser control over volume, speed, and
pitch, as well as transformational filtering (e.g. filtering specific
frequencies), etc.

Simon deals with audio for blind users, but does not believe he has
time to take on another working group right now.

Mark also believes there may be another person in his department who
is an expert on audio, and may be appropriate as an invited expert.

<mhakkinen> Antti pirhonen, university of jyvaskyla

This discussion was started last week. Comes from HTML5 WG
Accessibility Task Force. They want the browser to notify the user if
captions are requested but for some reason cannot be found or
displayed. They want this to be a UAAG requirement rather than in the
HTML5 spec.

A concern brought up last week was where would it stop: would UAAG
call out everything that could go wrong and that the user agent should
inform the user of?

Jeanne suggests a more generic success criterion saying that if there
is a problem rendering alternative content, there is some indication
given to the user.

Probably not an alert (dialog box), but some passive feedback
(equivalent to the broken image icon).

Question is would it be good enough if it's hidden by default, such as
in a developer panel?

<JAllan> gl: would it be visible in the default configuration? would
the user have to hunt for it?

<JAllan> if hidden in the developer panel no user (99%) will find it

Jim asks if there's a difference between "this video has no captions"
vs. "this video has captions but they're broken".

Jan suggested the error be displayed in a developer panel, which could
have many other similar errors as well.

General agreement that we should have a generic SC saying that the
user can tell when alternative content cannot be displayed, and the
Intent and Examples make clear that it is not recommended that the
notice require user response.

<JAllan> level AA or AAA

Also that the user should be able to have the status presented to them
instead of having to look it up in a separate context (such as an
error log)?

"The user can be notified (informed) when user user agent cannot
render alternative content (e.g. when captions are broken)." ?

Title: Broken Alternative Content?

Example: _____ has images turned off and replaced by their alt text.
When alt text is missing, an error icon is presented in its place.
... _____ is watching videos embedded in a Web page. The browser
enables a Captions button when it detects that a caption stream is
available. The user clicks this to turn on display of captions, but
the browser finds the caption stream is invalid. Instead of merely
showing blank space, it displays a small message or icon in the
caption area to inform the user that the requested...
... captions cannot be displayed.

<JAllan> This seems to fit in GL 1.2 Repair missing content

Intent: Users who have chosen to have alternative content presented to
them greatly appreciate understanding, when their request does not
seem to be working, whether that is due to a source error, user error,
or merely a delay.

Note that it is generally recommended that this type of notification
NOT require user response.

scribe: so as not to interrupt the user's experience.

<KimPatch> Intent: Users who have chosen to have alternative content
presented to them greatly appreciate understanding whether a
non-working requests is due to a source error, user error, or merely a
delay.

<mhakkinen> +1

+1

<JAllan> +1

<KimPatch> Copy error fix:Intent: Users who have chosen to have
alternative content presented to them greatly appreciate understanding
whether a non-working request is due to a source error, user error, or
merely a delay.

<JAllan> should this be AA?\

<mhakkinen> +1

<KimPatch> +1

<Jan> +1

+1 (but would be fine with AAA)

<jeanne> +1

<JAllan> +1 (fine with AAA also)

<sharper> +1

<Jan> (fine with AA as well)

<Jan> (fine with AAA as well)

I must admit that it's *nice* but lack of it would never prevent a
person from using the document/browser.

<JAllan> kp: this is informational, giving the user a mental map of
what is happening

1.2.x Broken Alternative Content: The user can be notified when user
user agent cannot render alternative content (e.g. when captions are
broken).

Intent:

Users who have chosen to have alternative content presented to them
greatly appreciate understanding whether a non-working requests is due
to a source error, user error, or merely a delay. Users who lack this
information may incorrectly conclude that a particular site is not
accessible to them, or may waste time either waiting for content or
attempting to find a non-existent problem in their...

scribe: browser or configuration.

Note that it is generally recommended that this type of notification
NOT require user response, so as not to interrupt the user's
experience.

Examples:

* _____ has images turned off and replaced by their alt text. When alt
text is missing, an error icon is presented in its place.

* Example: _____ is watching videos embedded in a Web page. The
browser enables a Captions button when it detects that a caption
stream is available. The user clicks this to turn on display of
captions, but the browser finds the caption stream is invalid. Instead
of merely showing blank space, it displays a small message or icon in
the caption area to inform the user that the requested...

scribe: captions cannot be displayed.

Related Resources: Success criterion 1.1.3 requires that the user be
informed when the document indicates that alternative content is
present, but the browser may not know that the alternative content is
broken until the user actually attempts to render or play it.

(Actually that could be in the Intent paragraph.)

<jeanne> ACTION: Jeanne to add the above to the documents as 1.2.x
[recorded in http://www.w3.org/2011/01/20-ua-minutes.html#action01]

<trackbot> Created ACTION-488 - Add the above to the documents as
1.2.x [on Jeanne Spellman - due 2011-01-27].

Jeanne feels we're close to last call, need to finish the Intent
document. Plan is to work on those during the next two conference
calls.

GL4 has all IER (Intent, Examples, Related Resources) done.

When we complete the IER for 3.4.2 then all of GL3 will be done.

1.9 is about focus, and Kim and Greg have done a lot on that but not
entirely finished.

They'll schedule time to continue working on that together.

<JAllan> 3.4.2 (former 5.4.2) Unpredictable focus:

<JAllan> The user is informed when the user agent changes focus. The
user agent provides a global option to block uninitiated focus
changes.

That's really two SC.

All of 3.4 is about focus, which is also the topic of 1.9.

<JAllan> http://www.w3.org/WAI/UA/2010/ED-IMPLEMENTING-UAAG20-20101215/#gl-focus-mechanism

Question about whether we should merge the two guidelines together.

Since "consistent behavior" (3.4) is a valid recommendation we'd like
to convey to developers, perhaps we can keep it around, even if its
only content is cross-references to SC in other guidelines
(particularly in 1.9 Effective Focus).

Jim notes that 1.8 also has a lot of focus-related criteria.
Summary of Action Items
[NEW] ACTION: Jeanne to add the above to the documents as 1.2.x
[recorded in http://www.w3.org/2011/01/20-ua-minutes.html#action01]

[End of minutes]

-- 
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, 20 January 2011 19:33:02 UTC