<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

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/guiedlines/guidelines/
Found Scribe: KimPatch
Inferring ScribeNick: KimPatch
Default Present: Jeanne, Greg_Lowney, Kim_Patch, Jan, Jim_Allan
Present: Jeanne Greg_Lowney Kim_Patch Jan Jim_Allan
Regrets: kelly simon jan_(partial) wayne
Found Date: 26 Apr 2012
Guessing minutes URL: http://www.w3.org/2012/04/26-ua-minutes.html
People with action items: jr

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.