minutes: 17 May 2012 UAWG telecon

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

User Agent Accessibility Guidelines Working Group Teleconference
17 May 2012

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

Present
    Greg_Lowney, Jan, Jeanne, sharper, Kim_Patch, Jim_Allan
Regrets
Chair
    Jim Allan, Kelly Ford
Scribe
    jallan

Contents

    Topics
        Face to Face planning
        Action-631 UAAG:next?
        Action-630 is this done?
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0070.html
    Summary of Action Items

Summary of Action Items
[NEW] ACTION: jan to write definition of stylesheet. [recorded in
http://www.w3.org/2012/05/17-ua-minutes.html#action01]
[NEW] ACTION: Jim to revise GL 1.7, pay attention to current behavior
and aspirational subpoints, adjust IER and add where necessary
[recorded in http://www.w3.org/2012/05/17-ua-minutes.html#action02]

<trackbot> Date: 17 May 2012
Face to Face planning

js: any request for items on agenda, or other issues.

ja: any dietary issues?

<Jan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#gl-style-sheets-config

<Jan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#def-stylesheet

<jeanne> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#def-style-grouping

gl: use term stylesheet, define broadly to cover other technologies

<jeanne> Most agreed they did not see that Style Rule and Style
Grouping designation was needed. There are no links to it.

gl: perhaps a note

<Jan> http://en.wikipedia.org/wiki/Style_sheet_%28web_development%29

<Jan> A web style sheet is a form of separation of presentation and
content for web design in which the markup (i.e., HTML or XHTML) of a
webpage contains the page's semantic content and structure, but does
not define its visual layout (style). Instead, the style is defined in
an external style sheet file using a style sheet language such as CSS
or XSL.

<jeanne> GL: I would keep the definition of Stylesheet, but it needs
to include non-CSS technologies.

<Greg> In particular, it is a set of style rules that can both be
separated from content and applied to content.

<jeanne> JS: CSS does not appear to define Stylesheet. However, they
do have a concept of Style Profile which is diffferent from what Wayne
was proposing, which strengthens my opinion not to use the term Style
Profile as it will be more confusing.

<Greg> Content that supports only inline styling would not count,
presumably, but what about a script that applied styles, or applied
inline stylings? If a script bolds every phrase ending in a colon, or
underlines every other word, would they count?

<scribe> scribe: jallan

<Greg> Ensure the final definition applies to non-markup (e.g. binary)
file formats, and that it is clear on whether or not scripts count,
and that the stylesheets can be separate from content and applied to
content.

<scribe> ACTION: jan to write definition of stylesheet. [recorded in
http://www.w3.org/2012/05/17-ua-minutes.html#action01]

<trackbot> Created ACTION-729 - Write definition of stylesheet. [on
Jan Richards - due 2012-05-24].

Resolution: remove other definitions related to style (profile, rule, etc.)

<Greg> Re 1.7.1 we could simply require that the same styling or
formatting mechanisms available to authors should be available to
users. For example, if authors can define a style sheet but users
could only define scripts, they might both be equally effective but
one is far more difficult.

ja: thought, last week we removed 'equally effective' from the SC, not testable

gl: what the method available to users is usable and as easy it is for authors.
... add a note in the intent. explaining the mechanism for users

resolution: remove words "an equally effective" replace with "a", and
use UAAG standard phrasing

<jeanne> 1.7.1 If the user agent supports a mechanism for authors to
supply stylesheets, the user agent also provides a mechanism for users
to supply stylesheets.

gl: level of 1.7.2, currently A, could be AA, quotes from email message

<Greg> It seems that 1.7.2 could be AA because the bare minimum
component, C, is already covered by 1.7.1; what 1.7.2 adds is the
ability to switch between that baseline and more complex behaviors (A
and B).

<Greg> I would not fail a browser from minimal accessibility because
it failed to do A and B, even though I would hope every browser would
do them.

<Greg> Jim, when working on 1.7.4 note that if you lose the part after
the comma (as per the email discussino) then you're left with the
problem of a lot of tools (e.g. Session Manager) that you can only
save and restore them on a single system, but cannot transfer them
between systems and cannot modify them. That would almost entirely
remove their usefulness.

<scribe> ACTION: Jim to revise GL 1.7, pay attention to current
behavior and aspirational subpoints, adjust IER and add where
necessary [recorded in
http://www.w3.org/2012/05/17-ua-minutes.html#action02]

<trackbot> Created ACTION-730 - Revise GL 1.7, pay attention to
current behavior and aspirational subpoints, adjust IER and add where
necessary [on Jim Allan - due 2012-05-24].

<jeanne> JS: when Wayne originally proposed these SC, Shawn Henry
(WAI's low vision person) recommended that the levels be AA or AAA.
Action-631 UAAG:next?

kim will write IER for new SC on user generated in page bookmarks
Action-630 is this done?
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0070.html

<Jan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120510/#def-point-of-regard

jr: if in an interactive movie, you click on some content that takes
you to a different site. you hit the back button you return to the
point in the movie you return to.

<Greg> If we want the definition of viewport to address both static
visual and audio/video, we could have two paragraphs in the
definition, one that starts "in video and audio..." and the other that
starts "in (something else)...". Better two simple definitions than
one very complicated one like we used to have for "viewport".

<Greg> The current definition has a lot of parentheticals, making it
difficult to read and comprehend.

jr: when zooming you zoom on a particular pixel. use that as a base

gl: but if I search, want the found item in the view port after zoom
... definition should be more general.

items that may b relevant to the def:

Starting with the base assumption that regardless of

other content that may have focus, or be selected, the current point

of regard is that information that is visible to the user with the

bounds of the viewport (user agent content area).

There are at least three cases where the user agent may have to take

action to keep the point of regard in essentially the same location

<trackbot> Sorry, couldn't find user - to

within the visible portion of the viewport: (a) the viewport is

resized; (b) the zoom/scale on the content is changed; or (c) the

formatting of some or all of the content changes (e.g. font or text

size, causing content to change height and/or rewrap).

In these cases the user agent should maintain the same top-left

(top-right for RTL) corner UNLESS there is a focussed/selected content

INSIDE the pre-zoomed viewport, in which case the focused/selected

content remains in the post-zoom viewport.

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

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

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

Starting with the base assumption that regardless of

other content that may have focus, or be selected, the current point

of regard is that information that is visible to the user with the

bounds of the viewport (user agent content area).

There are at least three cases where the user agent may have to take

action to keep the point of regard in essentially the same location

<trackbot> Sorry, couldn't find user - to

within the visible portion of the viewport: (a) the viewport is

resized; (b) the zoom/scale on the content is changed; or (c) the

formatting of some or all of the content changes (e.g. font or text

size, causing content to change height and/or rewrap).

In these cases the user agent should maintain the same top-left

(top-right for RTL) corner UNLESS there is a focussed/selected content

INSIDE the pre-zoomed viewport, in which case the focused/selected

content remains in the post-zoom viewport.

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

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

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

gl: should stay in the intent. how point of regard is used should stay in the sc

<Greg> "The point of regard is the position in rendered content" could
be "The point of regard is the portion of rendered content", or
perhaps "point or portion", but it's rarely if ever a real point;
normally it's at least a character which is larger than a point.

<Greg> Even if it's just the insertion bar, that has height, if not width.

sc 1.8.z Maintain Point of Regard: By default, when the user changes

viewport or content size the point of regard remains at the same

relative location within the visible portion of the viewport.

<Greg> Re 1.8.z, minor wording ambiguity "changes viewport or content
size", which could be read as "changes viewport, or changes content
size".

<Jan> 1.8.z Maintain Point of Regard: When the user resizes the
viewport or rendered content then the point of regard remains at the
same

<Jan> relative location within the viewport.

gl: should this be always, or a setting

<Jan> 1.8.z Maintain Point of Regard: When the viewport or rendered
content is resized, the point of regard remains at the same

<Jan> relative location.

gl: limiting to resizing.

<Greg> 1. should we indeed limit this to resizing?

<Greg> If the content changes, say a paragraph is added, or some
hidden content shown, does this still apply?

<Greg> I would say yes.

jim and jr +1

<Jan> 1.8.z Maintain Point of Regard: The point of regard remains at
the same relative location:

<Jan> (a) the viewport is resized

<Jan> (b) the rendered content is resized

<Jan> (c) rendered content is added or removed

gl: application, if I deleted something then the tool would shift the
content to the beginning of the content

<Greg> 2. Maintaining the relative location within the viewport is
less important than keeping the point of regard visible. For example,
let's say you do a Find and it highlights a sentence in the middle of
the viewport. Now you increase the zoom considerably, it's more
important for the entire highlighted sentence to be kept visible than
for the beginning of the sentence to still be in the middle...

<Greg> ...of the screen.

jr: 2 sc, 1 on resize and 2 on content modification

[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, 17 May 2012 18:40:27 UTC