Notes: User Agent Accessibility Guidelines Working Group Teleconference 21 Apr 2011

[Description: W3C]<http://www.w3.org/>

- DRAFT -
User Agent Accessibility Guidelines Working Group Teleconference
21 Apr 2011

See also: IRC log<http://www.w3.org/2011/04/21-ua-irc>

Attendees
Present
Jim, Kelly, Kim, Simon, Jeanne, Greg, Jan
Regrets
Chair
JimAllan, KellyFord
Scribe
jeanne, kford
Contents

  *   Topics<http://www.w3.org/2011/04/21-ua-minutes.html#agenda>
     *   2.7.4 http://www.w3.org/2002/09/wbs/36791/20110405/results#xq4<http://www.w3.org/2011/04/21-ua-minutes.html#item01>
     *   Proposals from Simon,<http://www.w3.org/2011/04/21-ua-minutes.html#item02>
     *   2.7.4<http://www.w3.org/2011/04/21-ua-minutes.html#item03>
     *   2.1.3 Keyboard Navigability<http://www.w3.org/2011/04/21-ua-minutes.html#item04>
  *   Summary of Action Items<http://www.w3.org/2011/04/21-ua-minutes.html#ActionSummary>

________________________________

<trackbot> Date: 21 April 2011

<kford> Scriber: kford

<kford> JA and GL talking about history on wiki changes.
2.7.4 http://www.w3.org/2002/09/wbs/36791/20110405/results#xq4
Proposals from Simon,
2.7.4

<kford> GL talking about changes proposed around title change for 2.7.4.

<Greg> It seems like for the purposes of structural navigation (e.g. go to next h2) and structural views (e.g. outline view) you'd certainly want the user to be able to define the set of important elements (e.g. only show headings of level 3 or higher). But for direct navigation and activation in content (e.g. Mouseless Browsing) would it be acceptable for it to just include all operable elements?

<Greg> Also, 2.7.4 uses the term "important (structural and operable) elements" which is elsewhere only the glossary "important elements", as differentiated from "operable elements".

<Greg> The two contrasting terms are used in:

<Greg> 2.7.4 Direct Navigation to Important Elements: The user can navigate directly to important (structural and operable) elements in rendered content. (Level A) . [Note: important elements are configurable per 2.7.7]

<Greg> 2.7.6 Direct Activation: The user can move directly to and activate any operable elements in rendered content. (Level AA)

<Greg> If we want to leave 2.7.4 as about important elements, then how about "2.7.4 Direct Navigation to Important Elements: The user can navigate directly to *important elements* in *rendered content*. (Level A) . [Note: important elements are configurable per 2.7.7]

<jeanne> scribe: jeanne

Greg: I was thinking about changing it to be more specific and removing the parenthetical phrase in the glossary term.

<Greg> "2.7.4 Direct Navigation to Important Elements: The user can navigate directly to structural and/or operable *important elements* in *rendered content*. (Level A) . [Note: important elements are configurable per 2.7.7]

Simon: I think when I wrote it, I did sequentially, so later I realized that one was about discovery, then the other was operation, which seemed to indicate a change in order.

<JAllan> http://www.w3.org/WAI/UA/work/wiki/Keyboard,_Focus,_and_Navigation_Restructuring

Simon: It seems to be saying that there is so much overlap that we may not want this SC at all and roll it into 2.3 Direct Activation and Navigation.

Jim: This is what is the last editor's draft without the changes that Simon made, but it should not be too hard to reconsile it.
... We have other two proposals that totally rearranged it all, then Simon's proposal is about changing the words, and then Greg and Kim have changed and reordered things.

Greg: and added things that weren't there before. I would prefer to go through things in sequential, and look for other things with outstanding edits, we can do them together in the wiki and reconsile them at that point.

Simon: I thought we had agreed on the SC and I was just working on the Intent and Examples.

Greg: Several more items had come up and we pushed them into that Action Item queue.

<Jan> +1 to Gregs idea - traverse according to kim-Gregs reorder proposal

Greg: 2.7.4 - we moved it, and put in Simon's Intent and Examples.

<Greg> To be clear, what I said was that we moved and renamed 2.7.4, but left it empty for putting in Simon's Intent, Examples and Related Resources.

<JAllan> wiki page on GL 2.7 http://www.w3.org/WAI/UA/work/wiki/Guideline_2.7

<kford> Group talking about multiple SC and sorting out work product from different individuals.

<Greg> The former 2.7 is now split into 2.3 and 2.5.

<kford> GL suggesting we review the proposal from he and KP, pulling in intents and proposals from SH as appropriate.

<JAllan> wiki page on GK proposal http://www.w3.org/WAI/UA/work/wiki/Keyboard,_Focus,_and_Navigation_Restructuring

<kford> JA: This sounds like a plan. Going to wiki page and starting to work through items.

<kford> JA: Starting with high level organization.

<kford> JA: Looks like a big reorg.

<kford> GL: This is correct5.

<kford> GL walking through changes, please see wiki for details.

<kford> Group looking at http://www.w3.org/WAI/UA/work/wiki/Keyboard,_Focus,_and_Navigation_Restructuring

<kford> J

<kford> JA asking if people need more time or comments.

<kford> JA: Any objections to include this text in the document.

<kford> JR: I'm assuming no SC have been dropped, this is just reordering.

<kford> KP and GL indicate yes, nothing dropped.

<kford> GL: We added active window and JA you asked if this meant active tab.

<kford> GL: We could say active viewport but that wouldn't mean necessarily you could identify the active window.

<kford> GL: Viewport could be an edit box in a frame in a tab in a window.

<Greg> So, the question is should we require the user agent visually distinguish the active window, active tab, pane, and/or viewport?

<kford> GL: When I added this I was thinking about window.

<kford> JR: Viewpoerts and windows are two separate things.

part of the viewport definition - When several viewports coexist, only one has the current focus at a given moment. This viewport is highlighted to make it stand out.

<kford> JR: Browsers use multitabs today but nothing stopping a browser from using windows as Word does where you can see multiple documents.

<kford> JA: It seems today we use tabs instead of multiple instances of browsers. But there can only be one active tagb at a time.

<Greg> For example, you can have open two browsers (e.g. Firefox and Chrome), and one of them can have multiple window, each window can have one or more tab viewports, each of which can have one or more frame viewports, each of which can have zero or more viewports such as scrolling divs text entry boxes, etc.

<kford> JR: I think of viewport like a window on a ship where you look into the world.

<kford> JR: Browsers today don't show multiple views into documents but they could.

<kford> KP: Making things plurual in expectation of the future might be the best.

<Greg> Viewports obviously nest, so do we want the SC to require highlighting just the innermost viewport that has the active keyboard focus, or the chain of them,as in saying the user should be able to tell which edit control has the keyboard focus, and its chain of ancestors (frame, tab, window)?

<kford> GL: Original intent was to help you identify where your keystrokes would be taking effect.

<Jan> +1 to chain

<JAllan> +1 chain

<Greg> Basically, the user needs to be able to visually recognize the active keyboard focus so that they know where their keystrokes will take effect. But to help them visually locate that keyboard focus indicator on a potentially complex and busy screen, it is useful for them to be able to narrow down their visual search based on visual indications of which window, tab, frame, etc. that focus...

<Greg> ...indicator is in.

<kford> JA: Any objections to using this chaining approach?

<Greg> However, we should consider what is already implemented, and how difficult it would be to add.

<kford> SH: Can someone give me an example of how this works when you are in a text box on a form?

<kford> JR: I think a form isn't a viewport unless it is a scrolling item.

<kford> GL: Items changing from viewport definitons is a bit confusing.

active viewport -> When several viewports coexist, only one has the current focus at a given moment. This viewport is highlighted to make it stand out.

<kford> kford: Viewport i9s pretty standard.

<Greg> I see that on June 4, 2010 I emailed Bert Bos (cc'ing the UAWG) asking for clarification on how the term viewport should be used, because of differences between CSS, WCAG, and UAAG usage.

<kford> JA: Any objections to calling window viewport, removing JA's comment and inserting in the document.

<kford> GL: What about people who have trouble viewing the active window.

<kford> SH: Are we talking about the content or the chrome?

<Greg> As a keyboard user, I find it very frustrating when an application has a custom window frame and provides no visual feedback of whether it is active or not, as that makes it difficult to tell where keystrokes like Alt+Esc have navigated to.

<kford> JR: Let's just add viewport. This covers these scenarios like tabbed interfaces in a web app.

<kford> JA: Any objections.

<kford> SH: None as long as we make it clear that this is native or recognized controls.

<scribe> ACTION: Jeanne to update document to add 1.3.1 from the wiki [recorded in http://www.w3.org/2011/04/21-ua-minutes.html#action01]

<trackbot> Created ACTION-525 - Update document to add 1.3.1 from the wiki [on Jeanne F Spellman - due 2011-04-28].

<kford> Issue: Ensure that our documents reflect the global concerns of native controls, recognized controls and overall give people clear guidance.

<trackbot> Created ISSUE-84 - Ensure that our documents reflect the global concerns of native controls, recognized controls and overall give people clear guidance. ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/84/edit .

<Greg> Former:

<Greg> 1.9.1 (former 3.11.1) Keyboard Focus: At least one keyboard focus is provided for each viewport (including frames), where enabled elements are part of the rendered content. (Level A)

<Greg> changed to:

<Greg> 2.1.2 Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times. (Level A)

<kford> JA: Hearing no objections on this one.

<scribe> ACTION: jeanne to update document with 2.1.3 from the wiki. [recorded in http://www.w3.org/2011/04/21-ua-minutes.html#action02]

<trackbot> Created ACTION-526 - Update document with 2.1.3 from the wiki. [on Jeanne F Spellman - due 2011-04-28].
2.1.3 Keyboard Navigability

<Greg> Since element refers only to content, what is a term that includes operable elements in content AND controls in the user agent user interface?

<kford> Group working through edits to existing text.

<kford> GL: KP do you think it is important to talk about extensions?

<kford> KP: Yes, but this can be in the intent.

<kford> KP: I recall why we had logical and such. You can have something be keyboard accessible but not very usable.

<kford> JR asking what we are adding here.

<kford> JA: Next week is our extended call. We start one hour earlier and go 90 minutes longer.

<scribe> ACTION: jeanne to update document with 2.1.3 from the wiki [recorded in http://www.w3.org/2011/04/21-ua-minutes.html#action03]

<trackbot> Created ACTION-527 - Update document with 2.1.3 from the wiki [on Jeanne F Spellman - due 2011-04-28].

<kford> Scribe: kford

Summary of Action Items
[NEW] ACTION: Jeanne to update document to add 1.3.1 from the wiki [recorded in http://www.w3.org/2011/04/21-ua-minutes.html#action01]
[NEW] ACTION: jeanne to update document with 2.1.3 from the wiki [recorded in http://www.w3.org/2011/04/21-ua-minutes.html#action03]
[NEW] ACTION: jeanne to update document with 2.1.3 from the wiki. [recorded in http://www.w3.org/2011/04/21-ua-minutes.html#action02]