minutes: UAWG 31 May 2012

from http://www.w3.org/2012/05/31-ua-minutes.html

- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
31 May 2012

See also: IRC log http://www.w3.org/2012/05/31-ua-irc
Attendees

Present
    Greg, Jim, Kim, Jeanne
Regrets
    Mark, Simon, Jan
Chair
    Jim Allan, Kelly Ford
Scribe
    kford, jallan

Contents

    Topics
        1.11.1 & 1.11.2 Action-467 Jim (revise for proposal) -
        Action-630 revised
        Action-733: definition of shortcut
    Summary of Action Items

<trackbot> Date: 31 May 2012

<JAllan> Latest editor's draft -

<JAllan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120524/

<kford> 1

<kford> Scribe: kford
1.11.1 & 1.11.2 Action-467 Jim (revise for proposal) -

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0092.html

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0091.html

JA going over research he did on this topic.

JA: My proposal was to leave 1.11.1 alone and just add the resources.

<JAllan> 1.11.1 Access Relationships: The user can access
explicitly-defined relationships based on the user's position in
content (e.g. show form control's label, show label's form control,
show a cell's table headers). (Level A)

JA: Bottom line is that 1.11.1 has remained unchanged.

Group talking about moving 1.11.1 to level AA.

KFord: I don't want to block on tablke headers.

<Greg> The wording "based on the user's position in content" is not
used elsewhere, and is somewhat vague, but not a show-stopper.

Resolved: 1.11.1 text staying the same. Level moving to AA.

<JAllan> scribe: jallan

kelly: reviews 1.11.2...its a mess. why is this needed, what is the
accessibility case

kf: if we didn't have this, who would it deny access to.

<jeanne> JA: I can see the doc type from the status bar

kf: how would folks feel about deleting 1.11.2

<jeanne> KF: The browser should expose the status bar, but that is
covered elsewhere

<jeanne> Greg: I'm not sure that opening a window or tab is the
problem that it once was.

gl: title covered by something else. not convinced that opening in new
window or tab is not as big a problem as it used to be.

<kford> Now to Kim: opening in a new window is one of the big complaints I hear.

<jeanne> ... but this SC is very different from what my users want

<kford> KFord: Kim can you clarify this.

kp: how to open content in a new window or tab

<kford> Kim: My users want to know how to opena link in a new window.

<scribe> scribe: kford

Kim: My users want to control this, if you can do that then their
needs would be covered.

<JAllan> scribe: jallan

kf: kim, explain accessibility reason for having this,

kp: can't see two tabs at the same time. easy to switch or see two
windows at the same time.

kf: IE and FF have settings for controlling open of links in new tabs or windows

kp: functionality is there, but it needs to be attached to the keyboard

ja: seems to be more of an education issue rather than functionality issue.

kf: control-enter opens in new tab, control-shift-enter opens in new window

kp: mouseless browsing numbers with a control to open in a new tab would work

kf: we have a SC for direct selection of links, but do we need another
SC for this new functionality

kp: after checking...all functionality is there. its just education

kf: 1.11.2 should be deleted

<scribe> scribe: kford

Resolved: group deleting 1.11.2

Issue: In UAAG next address need to be able to directly activate a
link and control target of the link opening i.e. new window, new tab
for speech users.

<trackbot> Created ISSUE-93 - In UAAG next address need to be able to
directly activate a link and control target of the link opening i.e.
new window, new tab for speech users. ; please complete additional
details at http://www.w3.org/WAI/UA/tracker/issues/93/edit .

<JAllan> close action-647

<trackbot> ACTION-647 Write a scoping NOTE about Guideline 4.1 closed

<JAllan> close action-467

<trackbot> ACTION-467 Revise 1.11.1 and 1.11.2 make proposal to the group closed

<scribe> ACTION: JS to delete 1.11.2 from document after group
consensus. [recorded in
http://www.w3.org/2012/05/31-ua-minutes.html#action01]

<trackbot> Created ACTION-734 - Delete 1.11.2 from document after
group consensus. [on Jeanne F Spellman - due 2012-06-07].
Action-630 revised

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0088.html

<jeanne> close action-467

<trackbot> ACTION-467 Revise 1.11.1 and 1.11.2 make proposal to the group closed

<Greg> Minor editorial: change "are true" to "occur" or the like.

<jeanne> close action-734 complete

<jeanne> action-734 complete

<jeanne> close action-734

<trackbot> ACTION-734 Delete 1.11.2 from document after group consensus. closed

<Greg> How about "The point of regard remains within the visible
portion of the viewport, and where possible at the same location
within the viewport, when any or all of the following occur..."

<Greg> The way I think of point of regard is it's whichever changed
most recently: the focus location, or selection, or find results, or
content at the leading edge of the viewport.

<Greg> Consider replacing "point of regard" with "area of regard" to
acknowledge the fact that it's usually not just a point but a region.

<JAllan> New definition:

<JAllan> point of regard

<JAllan> The point of regard is the portion of rendered content that the user

<JAllan> is presumed to be viewing. The dimensions of the point of regard may

<JAllan> vary. For example, it may be a two-dimensional area (e.g. content

<JAllan> rendered through a two-dimensional graphical viewport), or a point

<JAllan> (e.g. a moment during an audio rendering or a cursor position in a

<JAllan> graphical rendering), or a range of text (e.g. focused text). The

<JAllan> point of regard is almost always within the viewport, but it may

<JAllan> exceed the spatial or temporal dimensions of the viewport (see the

<JAllan> definition of rendered content for more information about viewport

<JAllan> dimensions).

<JAllan> The point of regard may also refer to a particular moment in time for

<JAllan> content that changes over time (e.g. an audio-only presentation).

<JAllan> User agents may determine the point of regard in a number of ways,

<JAllan> including, based on viewport position in content, keyboard focus, and

<JAllan> selection. The stability of the point of regard is addressed by 1.8.z

<Greg> What we really mean might be closer to "Where possible, the
*entire* point of regard remains within the visible portion of the
viewport, and at the same location within the viewport, when any or
all of the following occur..."?

<jeanne> how do we communicate these subtleties to the poor developer
trying to figure out what we mean?

Group continuing to discuss this topic.

<JAllan> leading edge, selected or focused, or whatever changed last
should remain in the viewport

<JAllan> 1.8.z Maintain Point of Regard: The point of regard remains at the

<JAllan> same relative location within the visible portion of the viewport when

<JAllan> any or all of the following are true:

<JAllan> (a) the viewport is resized; or

<JAllan> (b) the zoom/scale on the viewport is changed; or

<JAllan> (c) the formatting of some or all of the content changes (e.g. font or

<JAllan> text size, causing content to change height and/or rewrap).

<JAllan> UNLESS there is focused or selected content INSIDE the pre-zoomed

<JAllan> viewport, in which case the focused/selected content remains in the

<JAllan> post-zoom viewport.

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0088.html

<Greg> "To the extent possible, the point of regard remains visible
and at the same location within the viewport when the viewport is
resized, content is zoomed or scaled, or formatting of content
changes."

Jeanne: I like Greg's solution.

Kim: I like it as well.

<Greg> "The point of regard remains within the visible portion of the
viewport, and at the same location within the viewport, when the
viewport is resized, content is zoomed or scaled, or formatting of
content changes." We could relegate to the IER the recommendation of
what to do when viewpoint can no longer show the the entire point of
regard.

<KimPatch> "To the extent possible, the point of regard remains
visible and at the same location within the viewport when the viewport
is resized, content is zoomed or scaled, or formatting of content
changes."

<JAllan> 1.8.z Maintain Point of Regard:

<JAllan> Intent: It can be disorienting and confusing when a user changes the

<JAllan> viewport size or zooms the content and the current content shifts out

<JAllan> of the viewport causing different content on the same page to be

<JAllan> displayed in the viewport. Just as the location in audio does not

<JAllan> change when the user increases the volume, the current point of regard

<JAllan> should not change when the user changes the size of the window or

<JAllan> zooms the content.

<JAllan> Starting with the base assumption that regardless of other items that

<JAllan> may have focus, or be selected, the current viewport is that

<JAllan> information which is visible to the user within the bounds of the user

<JAllan> agent content area. When any of the SC conditions are met, the user

<JAllan> agent should maintain the same top-left (top-right for RTL) corner

<JAllan> UNLESS there is focused or selected content INSIDE the pre-zoomed

<JAllan> viewport, in which case the focused/selected content remains in the

<JAllan> post-zoom viewport. {repeated for emphasis}

<JAllan> Note: "Content" and "selected" are used because there may be cases

<JAllan> where the viewport is zooming into just part of an element (e.g. if I

<JAllan> select a few words of text that are part of a <p> and zoom in)

<JAllan> Examples of Success Criterion 1.8.z

<JAllan> -- Jorge is a low vision user. While viewing a webpage he sees a

<JAllan> picture with a caption that is too small to read. He highlights the

<JAllan> caption, then uses the browsers zoom feature to increase the size of

<JAllan> the content so he can read the caption. Through the zooming process

<JAllan> the highlighted caption remains in the viewport, allowing Jorge to

<JAllan> keep oriented on the caption and begin reading it when the appropriate

<JAllan> content size is reached.

<JAllan> Later while reading on a page, Jorge finds some text that is too large

<JAllan> to read. The beginning of the large text is at the top of the bowser

<JAllan> content area. He uses the zoom feature to make the content smaller.

<JAllan> the text is reduced to a confortable reading size and the beginning of

<JAllan> the text remains at the top of the browser window.

<JAllan> -- Melissa has a distraction disorder. She is doing research for

<JAllan> school. She scrolls the content so the relevant section heading the

<JAllan> top line of the browser. She resizes the browser so she can see her

<JAllan> notes and the browser at the same time. After resizing the browser the

<JAllan> heading is still the top line of the viewport.

<JAllan> -- Xu has a reading disability. He needs only the text on a page to be

<JAllan> larger. He is reading a page with footnotes that are too small to

<JAllan> read. Xu places the footnote at the top of the browser, and using the

<JAllan> increase font-size feature, he increases the font-size of the text on

<JAllan> the page. The footnotes stay on the top of the viewport.

<Greg> I'd add that in addition to being disorienting and confusing,
the user may be forced to expend considerable time and effort finding
and navigating back to the place where they were working.

<JAllan> Users may have to expend considerable time an effort to
re-navigate back to their previous point of regard.

<Greg> First sentence needs editing, as it runs on now.

<Greg> It could start "User can be confused and disoriented when the
area where they are working suddenly shifts outside the visible region
of the viewport... In addition, the user may be forced..."

<JAllan> close Action-630

<trackbot> ACTION-630 Propose SC on maintaining point of regard when
scaling the page closed
Action-733: definition of shortcut

<JAllan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0080.html

<JAllan> proposed:

<JAllan> *shortcut*

<JAllan> A command that's tied to a particular UI control or application

<JAllan> function, allowing the user to navigate to or activate the control or

<JAllan> function without traversing any intervening controls. A shortcut is

<JAllan> modality independent, meaning it is accessible by any input
method (e.g.

<JAllan> keyboard, mouse, speech, touch or gesture). Also see Modality

<JAllan> Independence Principle.

<JAllan> Shortcut definition*

<JAllan> *keyboard command (keyboard binding, keyboard shortcut or
accelerator keys)*

<JAllan> A key or set of keys that are tied to a particular UI control or

<JAllan> application function, allowing the user to navigate to or activate the

<JAllan> control or function without traversing any intervening controls (e.g.

<JAllan> "ctrl"+"S" to save a document). It is sometimes useful to distinguish

<JAllan> keyboard commands that are associated with controls that are
rendered in

<JAllan> the current context (e.g. "alt"+"D" to move focus to the address bar)

<JAllan> from those that may be able to activate program functionality that is

<JAllan> not associated with any currently rendered controls (e.g. "F1" to open

<JAllan> the Help system). Keyboard commands help users accelerate their

<JAllan> selections. Also see Shortcut.

GL: Trying to underand exactly what is meant by command.

Kim: A command is the act of communicating with a computer.

More discussion around this. Trying to get clarification.

<JAllan> scribe: jallan
Summary of Action Items
[NEW] ACTION: JS to delete 1.11.2 from document after group consensus.
[recorded in http://www.w3.org/2012/05/31-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, 31 May 2012 18:45:21 UTC