W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2011

Minutes: 03 Mar 2011 User Agent Accessibility Guidelines Working Group

From: Jim Allan <jimallan@tsbvi.edu>
Date: Thu, 3 Mar 2011 14:02:44 -0600
Message-ID: <AANLkTinVVQgiCWAXVg5RvxC+b0gYm0ew45pLnrvo9NBf@mail.gmail.com>
To: WAI-ua <w3c-wai-ua@w3.org>
from: http://www.w3.org/2011/03/03-ua-minutes.html

- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
03 Mar 2011

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

Present
    Simon, Kim, Jim, Jeanne, Greg, Kelly, Jan, Mark
Regrets
Chair
    JimAllan, KellyFord
Scribe
    KFord

Contents

    * Topics
         1. survey http://www.w3.org/2002/09/wbs/36791/20110301/results
         2. Action 501 Configure Position
         3. 282 restore default toolbars
         4. CTION-504 - New 2.9.1 Improve Foreground Legibility
         5. Action 503
         6. 1.8.5
    * Summary of Action Items

<trackbot> Date: 03 March 2011

<mhakkinen> mark is on IRC today.

<JAllan> Hi Mark

<mhakkinen> hi jim... having to listen to a conflicting call for the
next hour. will be on IRC.

<mhakkinen> sent my survey responses.

<scribe> Scribe: KFord

GL describes shuttle launch experience.
survey http://www.w3.org/2002/09/wbs/36791/20110301/results
Action 501 Configure Position

survey shows 4 accepts,

KP: I thought there might be more users. Low vision if you are going
back and forth. Same reason for people with hand problems.
... You don't want to go magnify one part of the screen and then go
magnify another. Users with cognitive concenrs too.

<jeanne> Kim +1

JA: Anyone have issues with adding these users?

No issues heard.

JA: Reads concern expressed by PL.

Clarification: is the "online" part of "online document processor" on
purpose? To me, that would suggest a web application / rich text
editor running inside

a browser, i.e. WCAG and ATAG territory, rather than UAAG.

JA: To me I think Patrick raises a valid point.

GL: I relize this is only an example but we should adjust to be a UAAG example.

SH: Reading this again I think I originally thought this was for web
apps but now I don't.

GL: I have two things. 1. Configure position as a title isn't
appropriate when you have more than this now.

JA: How about configure toolbar.

GL: There isn't much about configuring toolbars, just their content.
Do we want it to apply to show/hide of toolbars.

JA looking for itmes on toolbars in general. Not finding.

<scribe> ACTION: JA to write SC on general toolbar show/hide and such.
[recorded in http://www.w3.org/2011/03/03-ua-minutes.html#action01]

<trackbot> Created ACTION-513 - Write SC on general toolbar show/hide
and such. [on Jim Allan - due 2011-03-10].

GL: Haven't check toolbar definition but I want to ensure our
definition and SC apply to the broader definition of toolbars. For
example some apps distinguish between something that is docked versus
floating and separate from the main app window.

<scribe> ACTION: GL to write glossary definion for toolbar [recorded
in http://www.w3.org/2011/03/03-ua-minutes.html#action02]

<trackbot> Created ACTION-514 - Write glossary definion for toolbar
[on Greg Lowney - due 2011-03-10].

GL: In related resources it says WAI Aria but nothing indicates why we
are sending people to ARIA.

JA: ARIA would make sense if we were talking about a web app but since
we are not, yes ARIA should probably go.

SH explains why it was there, mostly hold over.

JA: Any disagreement from removing ARIA?

None heard.

JA gives further explanation to SH and asks to think about
incorporating GL's concerns about the bbroader definition.
282 restore default toolbars

JA Looks like we all accept.

Group goes over couple issues listed in survey.

Group talks about differing uses of silver surfer.

GL brings up concerns around derfaults here.

JS: I didn't think this was that big of a deal. Restoring defaults
could be a block, toolbars wouldn't be as much of a block.

<Greg> That is, we have the ability to restore all preference settings
to default, and this is the only or one of a very few narrower
categories of preference settings that we're giving their own reset.

JA: It seems like GL 2.5 is for the browser itself. We put 2.8
separate because it was for extensions, although we've now lost this
concept.
... Do we need to clarify 2.5 to be applies to the things that come by
default with the browser and 2.8 is for extensions i.e. things people
add?

GL: I don't think 2.8 is completely the same as 2.5. I think it is
worth while to call out that we suggest user agents let people restore
toolbar defaults.

JA: Do we need a SC that calls out extensions specifically.

Group seems to say no because these are just part of the user agent.

<Greg> I do think 2.8 is not redundant to 2.5; 2.5 says the user can
configure and restore preference settings, but it's up to other SC
such as 2.8 to call out specific preference settings we think user
agents should provide. I think it is worthwhile to call out that we
recommend user agents allow users to configure toolbars, which help
pointing device users (among others) just like configuring...

<Greg> ...keyboard mappings help keyboard and many AT users.
CTION-504 - New 2.9.1 Improve Foreground Legibility

<Greg> I'd have the SC explicitly apply only to "recognized"
background images. The fourth paragraph of the intent makes this
clear, but it wouldn't hurt to acknowledge it in the SC itself.

<JAllan> +1 to using recognized

<Greg> Do we have examples of user agents allowing the user to replace
the background image on a page? Do you think we can have them by the
time we publish?

GL: Restates concenrs expressed in survey.

Group talking about replacing of backgroud images and what this means
and what user agents support this or would support this.

Group going through different background image scenarios and resulting
problems e.g. white on white.

<Greg> I'm not sure replacing the background image (with solid color
or another image) is important enough to be Level A, since you can
omit the image and it's replaced by the normal solid background color.

JA: Any objection to removing the word replaced?

None heard.

<JAllan> New wording for SC: Improve Foreground Legibility: The user
can have all recognized background images shown or hidden.

<Greg> The second paragraph of Intent states "Users could have the
option to have non-transparent backgrounds of a solid color of their
choice drawn behind text, rather than turning off background images…."
It seems clear from the wording of the SC that this would *not* be
sufficient to conform, and therefore is merely a best practice that
could be done _in addition to_ conforming to the SC. If so...

<Greg> ...we should make that more explicit. Did you decide not to
have this be a separate SC?

Group continuing to work through GL feedback.

<Greg> The third paragraph of Intent says that "[when background
images] display is turned off the user agent should give users access
to any alternative content associated with them…" I'm not sure this
would be useful without giving the user feedback that a background
image has been hidden; without that few users would search through
dialog boxes just on the off chance that the page has a...

<Greg> ...background image that has alternative content. As discussed
before we do want to address the possibility of technologies allowing
alternative content for background images, even though HTML doesn't
yet support this, but since there are thus no implementations are we
allowed to require it? Or is the compromise to just (and hopefully
more clearly) recommend this as an additional best...

<Greg> ...practice that is more clearly states to not be a requirement
or addressing the requirement?

<Greg> "Because background images occasionally convey important
information, when their display is turned off, it is recommended that
the user agent give users access to any alternative content associated
with them, and either alternative content on the page or provide
feedback telling the user that alternative content is available. At
the time of this writing, HTML does not support alternative...

<Greg> ...content for background images, but this may be supported in
other technologies or future versions."

<Greg> Finally, now that drawing solid color behind text is not part
of the SC, the SC's title should be narrowed to match the SC wording,
such as "Hiding background images".

<Greg> (The broader title made sense when we were going to make the SC broader.)

JA: I'll rewrite this and put it on the list.
Action 503

JA brings up concerns expressed by PL in survey.

JA: Anyone unhappy with making this an or visual or audiotyr indicator?

<Greg> I think that there should be a visual indicator of paused if
there's visual presence, and audio feedback if there's only audio
presence (e.g. in an audio-only browser).

<Greg> I don't think it would be good for the user to go to a page,
see a still image in place of a paused video, and only a small chirp
indicates that there's paused media. But maybe that's just bad UI
design, not important enough to discuss in the doc.

Group talking about PL concern about audio that may be played only
from scrippt and where visual notification should appear.

GL: We could refine this to talk about when the user agent can recognize.

Anotyher idea around here was some frame notification like user agents
do for other blocked content.

JA will go through and rewrite.

<Greg> Ideally this would apply only to cases where the user agent can
recognize that the media is being played automatically on page load,
such as when the page defines a background (autoplay) audio. It would
not apply when scripts play media, since the user agent can't be sure
it's an auto-play, and may not be able to intervene in any case.
1.8.5

<JAllan> 1.8.5 (former 3.10.6) Viewport History:

<JAllan> For user agents that implement a viewport history mechanism
(e.g. "back" button), the user can return to any state in the viewport
history, restoring the prior point of regard, input focus and
selection. NOTE: This success criteria does not apply to web pages
that cause legal commitments or financial transactions for the user to
occur, that modify or delete user-controllable data in data...

<JAllan> ...storage systems, or that submit user test responses. (Level A)

<JAllan> Intent:

<JAllan> Typically, when a user goes to a new page the point of regard
is the top of the page. If the user returns to a previously viewed
page the point of regard should be restored to its position when the
user moved away from the page.

<JAllan> The intent of the note is to prevent users from

<JAllan> This will help users who may have difficulty re-orienting
themselves during a browsing session. This includes some users with a
memory or cognitive disability, some users with a physical disability,
and some users with serial access to content or who navigate
sequentially, for whom repositioning will be time-consuming.

<JAllan> note: This checkpoint only refers to a per-viewport history
mechanism, not a history mechanism that is common to all viewports
(e.g., of visited Web resources).

<JAllan> Examples:

<JAllan> Related Resources:

<JAllan> WCAG 3.3.4 http://www.w3.org/TR/WCAG20/#minimize-error

Group discussion exclusions.

Talking about if exclusions should exist or not.

Consensus is that probably do not need the exclusions.

GL: It seems like this isn't saying the user has to be able to back to
every place but when you do allow this, you need to do all the items
we've listed.

<JAllan> kelly: agree about removing exclusion, asking the UA to
interpret what is happening on a page/site

<Greg> I think we can safely say that when the user agent allows the
user to return to a page in the history (e.g. a "back" button) it
should restore point of regard, etc., as we're not saying the user
agent has to let the user go back to every page.

JA: Original 1.8.5 doesn't have the note.

<Greg> This SC is really saying two things, one is that it DOES say
the user can go back to any page, which we may not want to require,
and it also says that when the user does go back, point of regard etc.
are restored, which I think is safe to say. Maybe those should be
separate.

<Greg> It's also interesting that we nowhere require the user agent to
provide a back button or history, but we say if you do, you have to
let them go back to any page.

<Greg> I'd say have one SC recommending user agents provide history
mechanism where user can go back to past pages, but acknowledge that
there may be pages that the user should not be allowed to return due
to security, etc.

<Greg> Then a second SC that says when you do let the user go back to
a previous page, you should restore point of regard etc.

<Greg> Could there be user agents where a back button is not
applicable or recommended, such as a media viewer?

Group talking about cases where back shouldn't be supported.

<Greg> Although if the two portions have the same level I guess they
can be combined.

<JAllan> kelly: why is this an accessibility issue...having a history

<Greg> History and back buttons are an accessibility feature because
(a) it reduces memory load (b) it reduces typing and navigating (e.g.
re-typing URL into a address bar).

Any disagreement with SC saying we need a back button?

<Greg> Conclusion is that we'll have one SC that will both require a
history mechanism, allow the user to return to past pages except where
forbidden by author or security or similar requirements, and when
returning to a page the point of regard etc. will be restored.

<Greg> A related question: should returning to a page via the history
mechanism explicitly NOT reload the page (e.g. run initialization
scripts)? If scripts are run, etc. then returning to the previous
point of regard etc. may not be appropriate or possible (e.g. the
script moves the focus to a particular point.)
Summary of Action Items
[NEW] ACTION: GL to write glossary definion for toolbar [recorded in
http://www.w3.org/2011/03/03-ua-minutes.html#action02]
[NEW] ACTION: JA to write SC on general toolbar show/hide and such.
[recorded in http://www.w3.org/2011/03/03-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, 3 March 2011 20:03:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 3 March 2011 20:03:19 GMT