- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 26 Apr 2012 14:34:11 -0500
- To: WAI-ua <w3c-wai-ua@w3.org>
from: http://www.w3.org/2012/04/26-ua-minutes.html
User Agent Accessibility Guidelines Working Group Teleconference
26 Apr 2012
See also: IRC log http://www.w3.org/2012/04/26-ua-irc
Attendees
Present
Jeanne, Greg_Lowney, Kim_Patch, Jan, Jim_Allan
Regrets
kelly, simon, jan_(partial), wayne
Chair
JimAllan, KellyFord
Scribe
KimPatch
Contents
Topics
1.10.2 Action-639 Jan (revise for proposal)
viewports
zoom
viewports
1.3.3, 1.5.1 needs decision on whether it is done or not -
Action item 723 on Kim
Viewports
Summary of Action Items
Summary of Action Items
[NEW] ACTION: JR to To write glossary item for top-level viewport
(that it is the top rendered content viewport) [recorded in
http://www.w3.org/2012/04/26-ua-minutes.html#action01]
<trackbot> Date: 26 April 2012
<jeanne> trackbot, start meeting
<trackbot> Meeting: User Agent Accessibility Guidelines Working Group
Teleconference
<trackbot> Date: 26 April 2012
<JAllan> Newest editor's draft -
<JAllan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120419/
<JAllan> http://www.w3.org/WAI/UA/2012/ED-IMPLEMENTING-UAAG20-20120419/
<JAllan> http://www.w3.org/WAI/UA/2012/ED-UAAG20-20120419/#gl-style-sheets-config
wording in draft. Approve or not
1.10.2 Action-639 Jan (revise for proposal)
<JAllan> CURRENT WORDING:
<JAllan> 1.10.2 Outline View: An outline view of rendered content is
provided, composed of labels for important structural elements (e.g.
heading text, table titles, form titles, and other labels that are
part of the content). (Level AA) @@ 639
<JAllan> Note: The outline constitutes the important structural
elements for the user (See 1.10.3). A label is defined by each markup
language specification. For example, in HTML, a heading (H1-H6) is a
label for the section that follows it, a CAPTION is a label for a
table, and the title attribute is a label for its element.
Jan: I added navigable. Once we say navigable I think the keyboard is implied.
<JAllan> proposed:
Greg: I'm not sure whether a navigable outline view means that it's an
operable outline view.
<JAllan> 1.10.2 Outline View: A navigable outline view of rendered
content is provided, composed of labels for important structural
elements. (Level AA) @@ 639
<JAllan> Note: The important structural elements will depend on the
web content technology, but may include headings, table captions, and
content sections. Success Criterion 1.10.3 addresses user
configurability of the list of important structural elements.
Greg: there's two types of outline views -- one where you are
filtering content to only show the important element. That's like in
Word where you are using outline view. Then there's using a pane -- a
separate view on the document to reflect what's going on in the main
view. Like headings map in Firefox
Jan: I had in mind the second one
<JAllan> scribe: KimPatch
Greg: if it's the second one if you can navigate in it it doesn't
necessarily mean it has an effect on the main viewport. We want
changes once its visible in the main port
<JAllan> could we change 'navigable' to 'operable'
Jan: I meant something which helps you move your focus
... should be more clear that we need a sort of side view, not
replacing the original view, which is navigable outline view, but
actions and changes in focus they are also change the focus in the
main viewport -- we need to be clear that there's that relationship,
and the other way as well, changes in focus in the main viewport
change outline
Greg: need to be able to arrow through and then select what you want
to zoom to as opposed to having the main view change all the time.
<JAllan> this discussion seem to be implementation. perhaps put this
in the intent or examples
<Jan> 1.10.2 Outline View: A navigable outline view of rendered
content is provided, composed of labels for important structural
elements, that can be used to move focus efficiently to these elements
in the main viewport. (Level AA) @@ 639
<Jan> Note: The important structural elements will depend on the web
content technology, but may include headings, table captions, and
content sections. Success Criterion 1.10.3 addresses user
configurability of the list of important structural elements.
Greg: example on that last one -- and Thunderbird outline of all the
folders and on the right the contents of the folders. Changing which
folder is viewed can sit there and think for a while -- you want to be
able to navigate through the folder list without causing each one you
pass over to sit for a few seconds loading the new contents
Jim: I think you did a good job capturing that without being prescriptive
no objections
<JAllan> Resolution: update 1.10.2 1.10.2 Outline View: A navigable
outline view of rendered content is provided, composed of labels for
important structural elements, that can be used to move focus
efficiently to these elements in the main viewport. (Level AA) @@ 639
<JAllan> Note: The important structural elements will depend on the
web content technology, but may include headings, table captions, and
content sections. Success Criterion 1.10.3 addresses user
configurability of the list of important structural elements.
<JAllan> close Action-639
<trackbot> ACTION-639 Propose how to explain that 1.10.2 outline view
should be operable closed
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0030.html
viewports
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0043.html
zoom
<JAllan> 1.8.X: Zoom: The user can rescale content within graphical
viewports as follows: (Level A)
<JAllan> (b) Zoom-in: to at least 500% of the default size; and
<JAllan> (a) Zoom-out: to at least 10% of the default size, or such
that only one scrollbar is required.
<JAllan> JR: Changed top to 500%. It has implementations in Chrome, IE
and is more reasonable for a mobile browser.
<JAllan> 1.8.Y: Reflowing Zoom: The user can request that when
reflowable content in a graphical viewport is rescaled, it is
reflowed, such that one dimension of the content can fit into the
viewport without scrollbars. (Level AA)
<JAllan> DEFINTION: Reflowable content: Content that can be
arbitrarily wrapped over multiple lines. The primary exceptions
reflowable content are graphics and video. Author instructions not to
wrap content (e.g., nowrap) does not affect reflowability.
Jan: changed from 1000 because we have 500 implementations in chrome
and IE. Zoomed out to at least 10% or such that only one scrollbar is
required is handling the issue of not requiring to zoom so much that
there's Blank space
<JAllan> The primary exceptions reflowable should be The primary
exception to reflowable
<Jan> Reflowable content: Content that can be arbitrarily wrapped over
multiple lines. The primary exceptions reflowable content are graphics
and video. Author instructions not to wrap content (e.g., nowrap) does
not affect reflowability.
<Jan> Reflowable content: Content that can be arbitrarily wrapped over
multiple lines. The primary exceptions to reflowable content are
graphics and video. Author instructions not to wrap content (e.g.,
nowrap) do not affect reflowability.
Greg: minor concern about scrollbars -- in the mobile area no
scrollbars, so what you really mean exceeds the size
... slight concern about the last sentence of the definition --
understand what you mean, but liable to confuse. But we are saying is
there's inherently content that doesn't reflow and then there's
content which is conditional
<Jan> 1.8.X: Zoom: The user can rescale content within graphical
viewports as follows: (Level A)
<Jan> (a) Zoom-in: to at least 500% of the default size; and
<Jan> (b) Zoom-out: to at least 10% of the default size, or such that
the content does not exceed either the height or width of the
viewport.
<Jan> 1.8.X: Zoom: The user can rescale content within graphical
viewports as follows: (Level A)(a) Zoom-in: to at least 500% of the
default size; and(b) Zoom-out: to at least 10% of the default size, or
such that the content does not exceed one of the height or width of
the viewport.
<Greg> "fits within the height or width of the viewport"
<Jan> 1.8.X: Zoom: The user can rescale content within graphical
viewports as follows: (Level A)(a) Zoom-in: to at least 500% of the
default size; and(b) Zoom-out: to at least 10% of the default size, or
such that the content fits within the height or width of the viewport.
<JAllan> all: +1
<Jan> Reflowable content: Content that can be arbitrarily wrapped over
multiple lines. The primary exceptions reflowable content are graphics
and video. User should have the option to override author instructions
not to wrap content (e.g., nowrap).
<Greg> Author-specified formatting can specify that reflowable content
be treated as non-reflowable (e.g. HTML pre element, CSS white-space
and word-wrap attributes), but for accessibility purposes the user
should be allowed to override such formatting.
Jan: the only concern is that this is a glossary terms was putting
requirement in a glossary term
Greg: could say may
<Jan> Reflowable content: Content that can be arbitrarily wrapped over
multiple lines. The primary exceptions reflowable content are graphics
and video.
Greg: non-reflowable content are either things that are inherently
non-reflow like images or things that are treated as non-reflow bull
did to author and can be overwritten by user preference
<JAllan> Reflowable content: Content that can be arbitrarily wrapped
over multiple lines. The primary exceptions to reflowable content are
graphics and video.
<Jan> 1.8.Y: Reflowing Zoom: The user can request that when reflowable
content in a graphical viewport is rescaled, it is reflowed, such that
one dimension of the content can fit into the viewport without
scrollbars. (Level AA)
<JAllan> Good defintion
<Jan> 1.8.Y: Reflowing Zoom: The user can request that when reflowable
content in a graphical viewport is rescaled, it is reflowed, such that
one dimension of the content can fit within the height or width of the
viewport. (Level AA)
<Jan> Note: The user must be able to override author instructions not
to wrap content (e.g., nowrap).
<Jan> Note: The user can override author instructions not to wrap
content (e.g., nowrap).
<JAllan> +1
<Jan> 1.8.Y: Reflowing Zoom: The user can request that when reflowable
content in a graphical viewport is rescaled, it is reflowed such that
one dimension of the content fits within the height or width of the
viewport. (Level AA)
<Jan> Note: The user can override author instructions not to wrap
content (e.g., nowrap).
Greg: should be able to order it is recommended
<Jan> Note: The user can choose to override author instructions not to
wrap content (e.g., nowrap).
Greg: it would be good to cross reference whenever we say something
about the user should have control of that
... quite a few places where we say recommended in the intent paragraph
<Jan> Note: user agents are encouraged to allow the override of author
instructions not to wrap content (e.g., nowrap).
<Jan> Note: User agents are encouraged to allow user to override
author instructions not to wrap content (e.g., nowrap).
<JAllan> resolution:
<JAllan> 1.8.X: Zoom: The user can rescale content within graphical
viewports as follows: (Level A)(a) Zoom-in: to at least 500% of the
default size; and(b) Zoom-out: to at least 10% of the default size, or
such that the content fits within the height or width of the viewport.
<JAllan> 1.8.Y: Reflowing Zoom: The user can request that when
reflowable content in a graphical viewport is rescaled, it is reflowed
such that one dimension of the content fits within the height or width
of the viewport. (Level AA)
<JAllan> Note: User agents are encouraged to allow user to override
author instructions not to wrap content (e.g., nowrap).
<JAllan> glossary
<JAllan> Reflowable content: Content that can be arbitrarily wrapped
over multiple lines. The primary exceptions to reflowable content are
graphics and video.
Jim: are happy with that? Any objections?
<JAllan> no objections heard
<JAllan> reviewing:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0030.html
<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0030.html
viewports
<JAllan> GL: Support Orientation within Viewports (181, 182, 184, 1811)
<JAllan> GL: Provide Viewport Configuration (183, 186, 187, 1810, 18X, 18Y)
Greg: I don't understand what you mean by ever
Jim: wait until Jan returns to finish this
<Greg> Re Jan's 1.8.4 I don't understand how "ever" fits in; would it
mean once scrollbars are shown they are not hidden again once no
longer needed?
1.3.3, 1.5.1 needs decision on whether it is done or not - Action item
723 on Kim
Jim: we took part of 1.3.3 and added to 1.3.1. At the end of it it
looks like 1.3.1 is an artifact
<JAllan> 1.3.3 Highlighted Input Controls:
<JAllan> The user can have the following highlighted when they are
recognized: (Level AA)
<JAllan> (a) enabled controls that take input (e.g. push buttons,
radio buttons, check boxes, and text input fields, but not groupings
or static text and images) regardless of whether they are read-write
or read-only, and
<JAllan> (b) elements with scripted input handlers (e.g. images or
text ranges that have onClick or onKeyPress events) regardless of
whether the current state allows them to operate.
Jim: this is the original 1.3.3 -- a is now in 1.3.1
<Greg> That's the original version, here's Kim's rewrite:
<JAllan> 1.3.3 Highlighted Input Controls:
<JAllan> The user can highlight elements with scripted input handlers
regardless of whether the current state allows the input handlers to
operate when they are recognized. (Level AA)
<JAllan> (Intent of Success Criterion 1.3.3:
<JAllan> Users need to be able to easily discover what web content
they can interact with whether or not the current state allows input
handlers (e.g. images or text ranges that have onClick or onKeyPress
events) to operate when they are recognized.
<JAllan> Note: This success criterion works in conjunction with 1.3.1
Highlighted Items, which ensures that the user can highlight elements,
and with 1.3.2 Highlighting Options, which ensures that the user can
customize the highlighting to meet their visual or cognitive needs.
<JAllan> Examples of Success Criterion 1.3.3:
<JAllan> PLACEHOLDER
<JAllan> Related Resources for Success Criterion 1.3.3:
<JAllan> 1.1.3 Identify Presence of Alternative Content (Level A)
requires items with alternative content to be highlighted.
<JAllan> 1.3.1 Highlighted Items (Level A) requires highlighting of
additional classes, including the selection, the active keyboard
focus, and visited and unvisited links.
<JAllan> 1.3.2 Highlighting Options (Level A) requires the user be
able to customize the appearances of these highlights.
<JAllan> I made the edits to 1.3.3, marked by <ins>xxx</ins>
<JAllan> After thinking about 1.3.3 it seems to be a waste of ink.
Javascript is increasingly being abstracted to attached .js files. The
js triggers on @class or @id attributes and there is nothing in the
actual html (like onClick or onKeyPress) for the user agent to know
what to repair. That is the js behavior is unrecognized by the user
agent. onClick etc. are quickly falling out of favor, to me...
<JAllan> ...this seems like an AA repair of a nearly extinct coding
practice. I would propose removing it from the guidelines.
<jeanne> +1
Greg: however doesn't WCAG have this
Jim: no -- here it's like were repairing an extinct dinosaur
... the new rewrite of 1.3.3 is purely a repair function -- the user
can do something if the browser can't find the thing and the authors
are hardly doing the thing anymore. Five years ago this would have
been relevant, now technology has passed it by
<JAllan> new 1.3.1
<JAllan> 1.3.1 Highlighted Items:
<JAllan> The user can specify that the following classes be
highlighted so that each is uniquely distinguished: (Level A)## DONE 5
April 2012
<JAllan> (a) selection
<JAllan> (b) active keyboard focus (indicated by focus cursors and/or
text cursors)
<JAllan> (c) recognized enabled elements (distinguished from disabled elements)
<JAllan> (d) elements with alternative content (see 1.1.2)
<JAllan> (e) recently visited links
<JAllan> new intent for 1.3.1
<JAllan> Intent of Success Criterion 1.3.1:
<JAllan> Users need to be able to easily discover what web content
they can interact with. They need to highlight selection, content
focus, enabled elements and links (including recently visited links)
in order to successfully discover and interact with the web content.
<JAllan> On some pages controls may be difficult to discern amid a
large amount of other content, or may be styled in ways that make them
difficult to distinguish from other content.
<JAllan> This can be particularly difficult for people with visual
impairments, who may not be able to easily distinguish visual
differences that may be subtle or obvious to users with average
vision. This can also be difficult for people with some cognitive
impairments, who may have difficulty distinguishing between items with
similar or non-standard appearance. The ability to have these items...
<JAllan> ...visually distinguished can greatly help reduce the amount
of time or number of commands these groups require to examine a page.
<JAllan> Note: In addition to these required categories, it is
recommended that user agents also allow the user to highlight the
active viewport, even when it is a frame or similar within the active
window. This makes it much easier for the user to visually locate the
active focus.
<JAllan> Note: Platform conventions will dictate whether or not an
inactive keyboard focus (keyboard focus in an inactive viewport) is
visually indicated by an inactive cursor.
<JAllan> Note: the definition of visited and unvisited links is up to
the user agent. In some cases it might be links visited during the
current session, or in other cases links visited in the browser's
history until that is cleared.
Greg: definition of enabled elements -- that would include things that
are scripted
Jim: definition should be recognized, because enable elements to me
are links and form controls that you know are enabled and you can do
something with. JavaScript enabled are entirely different, the browser
knows something about them and the author has written a bunch of stuff
to make sure it appears in the tab loop or accepts a keypress --
that's outside
Greg: change the definition to say recognized enabled behaviors?
<Greg> "An element with *RECOGNIZED* associated behaviors that can be
activated through..."
Jeanne: we've been using recognized for a long time
<jeanne> 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 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 out" menu item).
Greg: we don't really need to change the definition of enabled
elements -- just saying there are some elements user won't be able to
detect or enable, whenever we are using enabled elements we need to
scope it to make sure it's elements that are recognized
Jim: 1.3.3 should go away, Kim agrees, Greg agrees
<Greg> It does look like the definition of enabled elements includes
scripted elements, so 1.3.3 is not needed.
<JAllan> resolution: remove 1.3.3
Jim: I just sent the e-mail on this to the list
Users need to be able to easily discover web content they can interact
with. They need to highlight selection, content focus, enabled
elements and links (including recently visited links).
Users need to be able to easily discover web content they can interact
with. The most effective way to do this is highlight selection,
content focus, enabled elements and links (including recently visited
links).
Users need to be able to easily discover web content they can interact
with. One effective way to do this is to highlight selection, content
focus, enabled elements and links (including recently visited links).
Users need to be able to easily discover web content they can interact
with. One effective way to do this is to enable highlights for
selection, content focus, enabled elements and links (including
recently visited links).
<Greg> Users need to be able to easily discover web content they can
interact with. One effective way to do this is to highlight enabled
elements and links (including recently visited links). They also need
to know where they are working, which is enabled by highlighting
selection and content focus.
<JAllan> resolution:
<JAllan> Intent of Success Criterion 1.3.1:
<JAllan> Users need to be able to easily discover web content they can
interact with. One effective way to do this is to highlight enabled
elements and links (including recently visited links). They also need
to know where they are working, which is enabled by highlighting
selection and content focus.
<JAllan> On some pages controls may be difficult to discern amid a
large amount of other content, or may be styled in ways that make them
difficult to distinguish from other content.
<JAllan> This can be particularly difficult for people with visual
impairments, who may not be able to easily distinguish visual
differences that may be subtle or obvious to users with average
vision. This can also be difficult for people with some cognitive
impairments, who may have difficulty distinguishing between items with
similar or non-standard appearance. The ability to have these items...
<JAllan> ...visually distinguished can greatly help reduce the amount
of time or number of commands these groups require to examine a page.
<JAllan> Note: In addition to these required categories, it is
recommended that user agents also allow the user to highlight the
active viewport, even when it is a frame or similar within the active
window. This makes it much easier for the user to visually locate the
active focus.
<JAllan> Note: Platform conventions will dictate whether or not an
inactive keyboard focus (keyboard focus in an inactive viewport) is
visually indicated by an inactive cursor.
<JAllan> Note: the definition of visited and unvisited links is up to
the user agent. In some cases it might be links visited during the
current session, or in other cases links visited in the browser's
history until that is cleared.
<JAllan> Examples of Success Criterion 1.3.1:
<JAllan> Jerry is a low vision user. He goes to a website that uses
styles to override visited link color. He wants to know what links
have yet to be explored. The user agent provides a dialog box for
setting overrides to author-selected link colors.
<JAllan> Jerry goes to a website with CSS styles that removes the
content focus outline. The user agent provides a dialog box for
setting overrides to the author’s CSS focus outline declaration.
<JAllan> Binh gets easily frustrated when he cannot locate the buttons
and links on a page, usually because they don't have the standard
appearance he's used to. By turning on the option to have all links
appear in bright purple, and all push buttons and the like drawn with
a bright purple border, he can easily scan the page and find the items
he's looking for.
Viewports
<JAllan> working on this message:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2012AprJun/0030.html
<Greg> "ever" -> "when"
<Jan> 1.8.4 Viewport Scrollbars: USERS CAN SPECIFY THAT graphical
viewports include scrollbars WHEN the rendered content extends beyond
the viewport dimensions, overriding any values specified by the
author. (Level A) ## DONE TPAC @@ 636
<Jan> 1.8.4 Viewport Scrollbars: USERS CAN HAVE graphical viewports
include scrollbars WHEN the rendered content extends beyond the
viewport dimensions, overriding any values specified by the author.
(Level A) ## DONE TPAC @@ 636
Greg: specify would mean could also opt not to have it
Jan: split 1.8 into 2
<JAllan> guidelines
Greg: wasn't there another one that went with it -- if you are moving
this one you might want to move the other one as well-- an SC that
recommends they provide a history mechanism
Jan: 3.2.2 is back button, done on March 15
Greg: those go together
Jim: should at least cross reference each other
Jan: agreed
<JAllan> resolution: 3.2.2. and 1.8.5 should cross reference each other
Jan although 1.8.5 might get a new number soon
<Jan> 1.8.3 Resize Viewport: The user can RESIZE GRAPHICAL viewports,
within the limits of the display, overriding any values specified by
the author. (Level A) ## DONE TPAC
<JAllan> resolution: new 1.8.3 Resize Viewport: The user can RESIZE
GRAPHICAL viewports, within the limits of the display, overriding any
values specified by the author. (Level A) ## DONE TPAC
Jan: 1.8.7 -- added the word graphical
Greg: wording -- tabs -- anything inside a window is not a top-level window.
... a top-level window is a top-level viewport and I would think that
anything inside that would not be a top-level viewport.
Jan: top-level graphical viewport is the top-level viewport that is
displaying content. top-level is not content, each of the tabs has
content.
<Greg> The current definition of "top-level viewport" does not address
what it's used for (displaying a document, etc.), only about whether
it's inside another viewport, and if a window is a viewport, then tabs
are not top-level viewports. We could fiddle with the definition of
top-level viewport.
Greg: what you're saying makes sense, but maybe the definition of
top-level viewport is wrong
Jan: there are some cases where there's only one window and that's it,
that's what we are talking about
Greg: leave 1.8.7 as you suggested, then adjust the definition of top
level graphical viewports
Jan: we mean top level with respect to the rendering of web content
not necessarily with respect to the design of a Windows program
Greg: if you go to a webpage and it's got a toolbar at the top like
Google docs -- stuff framing around the actual content of the document
-- which of those is the top level -- in that case the chrome to
display the Google Doc is content
Jan: iIE top viewport is rendering content. Now Google docs, what is
its top level that it's rendering -- it's this other Web content that
starts at this point and goes down from there.
... top-level viewport, we mean the top-level that's rendering
content, not just its own implementation because you can imagine
something that's nested all over the place
<Jan> ACTION: JR to To write glossary item for top-level viewport
(that it is the top rendered content viewport) [recorded in
http://www.w3.org/2012/04/26-ua-minutes.html#action01]
<trackbot> Created ACTION-727 - Write glossary item for top-level
viewport (that it is the top rendered content viewport) [on Jan
Richards - due 2012-05-03].
Jeanne: maybe should have all the viewport stuff in one place
Jim: that would mean 12 guidelines under principle . 2.11 has 12
Greg: the thing about splitting it is if you look at the guidelines it
says something meaningful, more broad if we put them together
Jim: we'll pick this up next week
... what was accepted, if we are splitting etc.
... Jan started a conversation on 1.7, we need to comment. We'll start
with this one next week
[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, 26 April 2012 19:34:39 UTC