W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2010

minutes: UAWG Weekly Teleconference 2010-09-09 [draft]

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Thu, 9 Sep 2010 20:17:38 +0100
To: w3c-wai-ua@w3.org
Message-Id: <20100909191558.M27111@hicom.net>
aloha!

minutes from the 9 September 2010 UAWG weekly teleconference can be
accessed as hypertext from:

http://www.w3.org/2010/09/09-ua-minutes.html

as an IRC log from:

http://www.w3.org/2010/09/09-ua-irc

and as plain text following my signature -- please report any errors,
mis-attributions, clarifications, corrections and the like by 
replying-to this announcement on-list...

note that the following RESOLUTIONS were logged at the 2010-09-09
UAWG telecon:

  resolution: address bug 8647 in UAAG 2.0

  resolution: UAAG will not take up bug 8666 -- covered by UAAG
  already

  resolution: bug 8682 is a UAAG issue, not an HTML5 issue; need to
  discuss need for indicator for when author provided context menu
  different from standard context menu

  resolution: bug 8743 (auditory icons clashing with AT) is a UA
  issue; UAAG should highlight user control over such events

and that the following new action items were assigned:

  * ACTION-446: kford to look at longdesc issue with Gregory. Other
  also indicating they will look. 
  * http://www.w3.org/2010/09/09-ua-minutes.html#action01
  * http://www.w3.org/WAI/UA/tracker/actions/446

  * ACTION-447: Gregory - send proposed bug report on IFRAME and FRAME
  requesting that @title be required (used by AT to identify FRAMEs
  and IFRAMEs to user)
  * http://www.w3.org/2010/09/09-ua-minutes.html#action02
  * http://www.w3.org/WAI/UA/tracker/actions/447

  * ACTION-448: Jim to review notification of existence of author
  context menu see bug 8682 
  * http://www.w3.org/2010/09/09-ua-minutes.html#action03
  * http://www.w3.org/WAI/UA/tracker/actions/448

  * ACTION-449: Greg - work with GJR to write up wording to address
  bug 8751 so that highlight that it is allowed and not prohibited for
  HTML WG [recorded in
  * http://www.w3.org/2010/09/09-ua-minutes.html#action04
  * http://www.w3.org/WAI/UA/tracker/actions/449
  
special thanks to kelly for scribing when i spoke, gregory.

    _________________________________________________________

                             - DRAFT -

  User Agent Accessibility Guidelines Working Group Teleconference

09 Sep 2010

  See also: IRC log http://www.w3.org/2010/09/09-ua-irc

Attendees

  Present
         AllanJ, Greg, Gregory_Rosmaita, Jan, Jeanne, KimPatch, kford,
         sharper

  Regrets
  Chair
         JimAllan_KellyFord

  Scribe
         Gregory_Rosmaita

Contents

    * Topics
        1. Announcements
        2. Accesskey Replacement Requirements
        3. Verbose Descriptor Requirements (longdesc versus
           enhanced native describedby)
        4. HTML A11Y bugs relating to UA from Michael Cooper -
          
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0061.html
        5. Writer's Surveys
        6. Browser Implementations
    * Summary of Action Items
    _________________________________________________________

  <trackbot> Date: 09 September 2010

  <oedipus_away> scribe: Gregory_Rosmaita

  <oedipus_away> scribenick: oedipus

  <kford> we should take up the browser item last, I think that is
  item 5.

Announcements

  JA: take up agendum 5 first -- HTML WG deadline for bug submission
  2010-10-01
  http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html

  GJR: full details of HTML5 timeline:
  http://lists.w3.org/Archives/Public/public-html/2010Sep/0074.html

Accesskey Replacement Requirements

  http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements

  http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

  <inserted> scribenick: kford

  Gregory: I need to work with folks to get an access key replacement.
  ... There were 9 requirements from PFWG and I've logged various
  replies on a wiki page.
  ... I need to finish the process of going through 4.1 and making
  sure it reflects all the requirements that PF has.
  ... Does that seem like a reasonale process?

  JA: Yes.

  Gregory asks if there other places in UAAG to look.

  Group replying we do not think so but can check again.

  Group now thinking need to look under some parts of perceivable
  section.

  Gregory: I'll break this down and hopefully we can discuss this next
  week.

  <Greg> Here is the SC about presenting shortcut keys: 4.1.6 Present
  Direct Commands in Rendered Content: The user can have any
  recognized direct commands (e.g. accesskey) in rendered content be
  presented with their associated elements (e.g. "[Ctrl+t]" displayed
  after a link whose accesskey value is "t", or an audio browser
  reading the value or label of a form control followed by "accesskey
  control...

  <Greg> ...plus t"). (Level A)

Verbose Descriptor Requirements (longdesc versus enhanced native
describedby)

  <oedipus> longdesc:
  http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs - HTML A11y
  TF to determine if shoud be logged as issue (since there is no
  mechanism currently in HTML5 that provides for a verbose descriptor)
  or as a bug

  Gregory, as everyoe knows, longdesc has been removed from HTML5.
  Currently, no replacement for a verbose descriptor.

  Gregory: Would be good if people could review requirements.

  <oedipus> 1. A programmatic mechanism to reference a specific set of
  structured content, internal (enhanced describedby model) or
  external (HTML4 longdesc model) to the document containing the
  described image.

  <oedipus> 2. A way to inform users and authors that a description is
  present/available.

  <oedipus> 3. A device independent way to access the descriptive
  content.

  <oedipus> 4. An explicit provision that accessing descriptive
  content, whether internal or external to the document containing the
  image, does NOT take the user away from the user's position in the
  document containing the image where the verbose descriptor was
  invoked;

  <oedipus> 5. A way to provide user control over exposition of the
  descriptor so that rendering of the image and its description is not
  an either/or proposition. (A visual indicator of the description
  should NOT be a forced visual encumbrance on sighted users by
  default).

  <oedipus> 6. A method to reference a longer description of an image,
  without including the content in the main flow of a page.

  Gregory: Two possibilities. Keep longdesc with some adjustment.
  ... Other possibility is aria describedby
  ... Each of these has limitations.
  ... Bugs have been filed on this.

  <oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455

  <oedipus> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10017

  <oedipus> jeanne, bugzilla bug
  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10525

  <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

  <scribe> ACTION: kford to look at longdesc issue with Gregory. Other
  also indicating they will look. [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action01]

  <trackbot> Created ACTION-446 - Look at longdesc issue with Gregory.
  Other also indicating they will look. [on Kelly Ford - due
  2010-09-16].

HTML A11Y bugs relating to UA from Michael Cooper -
http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JulSep/0061.html

  <inserted> scribenick: oedipus

  JA: reply not made to list yet
  ... sent message to list -- 5 bugs reported by HTML A11y TF as UAWG
  concerns
  ... first: 8647 - tab order for IFRAME (when IFRAME processed, tab
  order in doc should be outside iframe, when get into iframe follow
  its tab order, when move off iframe, resume tab order at next tab
  following last tab that put user in iframe
  ... might be similar to flash issues where things get inserted in
  DOM tree -- tab into and tab out into regular content and document
  flow
  ... compound document implications
  ... question: in IE and FF can use F6 to move between frames on
  windows platform -- if in IFRAME should be able to use F6 to jump
  from IFrame to main content

  GL: F6 is cycle through frames -- don't know if concept of main
  frame / parent exists
  ... main viewport in which other viewports are contained

  KF: what if have page with 2 frames but no iframe

  KP: important to have a sure thing -- if toggling between things
  cannot do command to go to place x and do something

  JA: can with AT

  KP: cannot do it with speech with a toggle
  ... useful to have command to put to known place
  ... really useful thing to be able to directly get to a known place

  KF: IE design philosophy -- F6 is a pane-cycling key -- ALT+D
  (address bar) is known place to return
  ... if use SHIFT+F6 to navigate panes in reverse

  q

  <Zakim> oedipus, you wanted to say need aria role=iframe

  GJR: aria role=iframe that would make the iframe a landmark that
  could be easily navigated to

  JA: seems like overkill -- iframe just another type of frame -- can
  use F6 to jump between iframe
  ... iframe should show up as part of frames list -- 1 less thing for
  author to have to do and get wrong

  KF: address in HTML5 or in UAAG?

  JA: this is one that UAAG needs to address unless go with
  role=iframe

  GJR: role=iframe is a non-starter -- already have a last call draft
  in place
  ... there has been talk of ARIA 1.1 as opposed to waiting for ARIA
  2.0 for which there is an extensive wish list

  JA: recommend adding GL to UAAG if don't already have one

  proposed resolution: address bug 8647 in UAAG 2.0

  resolution: address bug 8647 in UAAG 2.0

  JA: next bug title attribute on iframe
  ... suggest including advice on having title on IFRAME for
  navigation
  ... HTML4 had @name ATs used to identify iframe to user
  ... AT or other mechanism could use @name -- issue: @name is not
  required -- if were would be beneficial

  GJR: didn't @name get deprecated in favor of @id

  JA: name attribute required?

  KF: this is on iframe specifically?

  http://www.w3.org/WAI/PF/wiki/IFRAME

  KF: @name becomes title for embedded document

  JA: HomePageReader used to go to URI of IFRAME src and pull out its
  TITLE -- otherwise used @name value
  ... what to do?
  ... iframe should be treated as frames and use a11y stuff used for
  frames -- UAAG should address how to handle FRAME and IFRAME --
  would be nice if @name was required -- right now @name, @id, and
  @title are optional

  KF: for a11y want to use @title versus @name -- @name programmatic
  concept
  ... don't think is specific thing UAAG needs to tell HTML5 to change

  GJR: can file a bug stating that @title should be required on IFRAME
  and FRAMES

  JA: that would solve a whole host of issues

  GJR: what i will i will send a proposed bug report to ua list and
  then we can discuss before i log it in the HTML5 bug tracker

  <scribe> ACTION: Gregory - send proposed bug report on IFRAME and
  FRAME requesting that @title be required (used by AT to identify
  FRAMEs and IFRAMEs to user) [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action02]

  <trackbot> Created ACTION-447 - - send proposed bug report on IFRAME
  and FRAME requesting that @title be required (used by AT to identify
  FRAMEs and IFRAMEs to user) [on Gregory Rosmaita - due 2010-09-16].

  GL: could use a DIV for everything an IFRAME couldn't one?
  ... can set flow attribute to auto -- IFRAME has fixed size

  JS: DIV won't let you embed external document

  GJR: points out some issues with iframe resizing -- have to use
  sandbox attribute

  <Greg> From the user perspective there is no difference...

  JA: date picker -- a11y concerns expressed for date picker applies
  to almost everything

  KF: question to ask ourselves is do we give enough guidance in SC to
  make controls accessible?

  JA: have that in "everything should be keyboard accessible"

  proposed resolution: UAAG will not take up bug 8666 -- covered by
  UAAG already

  resolution: UAAG will not take up bug 8666 -- covered by UAAG
  already

  JA: bug 8682 - tab and reading order for context menus
  ... should be defined in spec to clarify usage; editor says "don't
  understand is a platform specific issue"
  ... addition of context menu into native context menu of particular
  item or provide one for the user when not provided
  ... for UAAG, use arrow keys in windows to move through context menu
  after opening
  ... do we need an indicator for when author provided context menu
  different from standard context menu
  ... think this is a UAAG issue and not an HTML5 issue

  KF: agree
  ... should discuss need for indicator

  JA: any disagreement that is UAAG issue and not HTML issue?

  resolution: bug 8682 is a UAAG issue, not an HTML5 issue; need to
  discuss need for indicator for when author provided context menu
  different from standard context menu

  <AllanJ> ACTION: Jim to review notification of existence of author
  context menu see bug 8682 [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action03]

  <trackbot> Created ACTION-448 - Review notification of existence of
  author context menu see bug 8682 [on Jim Allan - due 2010-09-16].

  JA: bug 8743 --- auditory icons clashing with AT
  ... icons in HEAD of document could be visual/aural/olfactory/etc.
  ... are auditory icons meant to be played by UA when page loads
  ... HTML editor said how icons displayed and act is a UA issue
  ... agree with editor -- how UA should handle auditory icons should
  be handled by UA under user control

  KF: agree

  GL: 1 concern: don't disagree, but when HTML spec defines something
  but doesn't define how to be used, get diff implementations from
  different browser devs
  ... similar to issue with @title -- how to expose?
  ... personally think is bad not to provide some guidance as to how
  can be used
  ... UAAG should outline user control over auditory events

  JA: sounds like another configuration thing

  GJR: user should be able to decide how things are done (per instance
  or as universal setting)

  resolution: bug 8743 (auditory icons clashing with AT) is a UA
  issue; UAAG should highlight user control over such events

  issue: bug 8743 (auditory icons clashing with AT) is a UA issue;
  UAAG should highlight user control over such events

  <trackbot> Created ISSUE-73 - Bug 8743 (auditory icons clashing with
  AT) is a UA issue; UAAG should highlight user control over such
  events ; please complete additional details at
  http://www.w3.org/WAI/UA/tracker/issues/73/edit .

  JA: last bug 8751 - user should have ability to override automatic
  scrolling
  ... can use HTML5 to scroll element into view -- when detected,
  supposed to put element into viewport
  ... should be way for user to override automatic scrolling because
  auto-scroll may entail much more work on part of user
  ... editor said scrolling req is a SHOULD not a MUST -- must bring
  to user's attention but agnostic on how should be done
  ... this is a specific scripting thing being added to HTML5
  affecting UA behavior
  ... if in HTML5, may know what is being done and how to control

  <AllanJ>
  http://www.w3.org/TR/html5/editing.html#scrolling-elements-into-view

  http://www.w3.org/Bugs/Public/show_bug.cgi?id=8751

  JA: if it is in HTML5, UA should know what is going on, so UA should
  have ability to control whether happens automatically or only on
  specific request
  ... if just javascript, UA won't have a clue -- should ask author to
  assign ARIA politeness level to it so user can make decision to auto
  scroll or not
  ... HTML5 has hundreds of these javascript "standardization"
  ... should all of this stuff in HTML5 will inform what UAs will do
  with DOM manipulation or will it go into javascripted black hole

  JR: dont' mention focus -- strange

  GL: think that is intentional

  JA: scrolls whole object into view but doesn't put programmatic
  foucus on object

  JR: doing something that will cause user's attention to it, but
  haven't moved focus

  GL: use case: have 2 panes -- 1 where user is working, 1 where info
  about background tasks; want to scroll 1 pane into view without
  causing focus to move so user can return to pane 1

  KP: googledocs - when delete or paste, jumps to top of doc;
  WordPress - if delete comment from bottom, jumps to the top, so have
  to delete them one-by-one

  JR: this could be a fix for that?

  KP: if user could say "don't move my focus"

  GJR: KP are you saying "don't move focus, but you can move my
  viewport if you bring me back to original focus?

  GL: document will be taken by devs as instructing them to scroll in
  all cases -- title is "scroll into view" and states SHOULD scroll
  (although non-normative) -- key part is MUST focus but doesn't state
  how
  ... acknowledge that user settings may change behavior -- most
  authors will never read UAAG so would be good to have in HTML5
  directly

  KF: if we want something need to propose a change

  JS: most effective way to get done is propose a change

  GJR: 2 steps: 1 log bugs - 2. write change proposal for HTML WG

  <Greg> It would be NICE but not absolutely required for the HTML
  document to acknowledge that user preference settings can change how
  this is handled. We can and should put it in UAAG but many
  developers won't read it.

  JS: need to reopen bugs

  GJR: need to take bug 8751 and put them in a change proposal on HTML
  WG wiki

  KP: user settings can affect this

  GL: would prefer them to change wording slightly so that more
  context available before user starts scroll
  ... if can find implementations should at least make recommendation;
  wording in a number of places could allow for that rather than
  seeming to prohibit it

  JA: could you write something up on this GL?
  ... please work with GJR on this

  <scribe> ACTION: Greg - work with GJR to write up wording to address
  bug 8751 so that highlight that it is allowed and not prohibited for
  HTML WG [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action04]

  <trackbot> Created ACTION-449 - - work with GJR to write up wording
  to address bug 8751 so that highlight that it is allowed and not
  prohibited for HTML WG [on Greg Lowney - due 2010-09-16].

  <Greg> Also, it would be nice for the HTML5 document to acknowledge
  that user preference settings could let the user specify the size of
  a buffer around the edge of the viewport such that when scrolling to
  found etc. content that content would not appear at the very edge of
  the viewport, but instead inset somewhat so the user can see more
  context around it without having to scroll. UAAG20 could...

  <Greg> ...include a low-priority recommendation (e.g. Level AAA)
  that UA provide such a setting.

  JR: author wants info of use to user -- want attention to be on
  object x -- for mouse user bringing something into middle of
  viewport, makes easy to mouse links -- if focus left behind, then
  those links are no closer for non-mouse user
  ... if telling people attention should be here, focus should be here
  too?

  GJR: will author use HTML5 details element or aria-dialog?

  JR: like 2 pane work use case -- if second pane isn't allowed to
  scroll, not getting full functionality

  KP: can you fix if author broke it

  JA: could be user setting -- if viewport moves, have focus move with
  it

  GL: what authors want to do is move focus, not scroll into view
  ... when author explicitly does not want to move focus, would be
  useful to retain focus in one pane while providing viewport for
  second

  <Greg> The HTML5 document should probably give more guidance on when
  authors would use scrollIntoView vs. moving the focus (which also
  scrolls things into view in the default configuration). Authors
  should almost always move the focus rather than using scollIntoView,
  except in very specific circumstances where they REALLY want to
  bring something to the user's attention WITHOUT stealing the
  keyboard...

  <Greg> ...focus.

  KP: best case - user gets info - if overriden, notify getting
  something different;

  JR: "before you use scroll into view, make sure you do not want to
  move focus..."
  ... "scroll element into view without moving focus to element"

  JA: are we covered?

  GJR: are we also saying "don't move focus, but you can move my
  viewport if you bring me back to original focus?

  JA: GL 3.10 "help user to use viewports and orient within them"
  ... indicate viewport position -- all in GL 3.10
  ... have a lot of that covered

  investigate scrollIntoView crossover with ARIA politeness levels and
  live regions

  JA: can scrollIntoView be first thing on page so user is placed in
  middle of document?
  ... example: google search puts focus in edit box
  ... propose Greg and Gregory get wording ready to submit to HTML5 --
  find out what is response, then follow up if needed
  ... need to remember to bump up GL 3.10 to make sure that cover this
  in implementation of viewports

  FIVE MINUTE WARNING

Writer's Surveys

  JA: where to start?
  ... don't know if have enough time to get to any of them

  KF: take up next week with survey 3

Browser Implementations

  KF: would like WG review of all success criteria -- think we are
  close, but when reviewed ATAG, noticed that drafting very crisp --
  where can UAAG 2.0 be tightened up especially in regards SC

  JR: ATAG got major feedback -- may have to cycle back to WD --
  cautionary tale for UAAG 2.0

  KF: GL you have ATAG comments?

  GL: yes, need to divide between high priority and regular priority
  ... submit as go or wait for comprehensive feedback

  JR: would like to get as much feedback as soon as possible -- AUWG
  having F2F next week to process LC issues
  ... stabilization draft feedback is what we need
  ... people have pavlovian response to the term "Last Call"

  JS: getting other WAI groups feedback before LC is key

  JR: UAAG feedback to AUWG good --
  ... also received substantive issues from other sources, which is
  why may have to cycle back through another PWD and another LC

  [ADJOURN]

  jeanne, the bug on bugzilla is:
  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10525

Summary of Action Items

  [NEW] ACTION: Greg - work with GJR to write up wording to address
  bug 8751 so that highlight that it is allowed and not prohibited for
  HTML WG [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action04]

  [NEW] ACTION: Gregory - send proposed bug report on IFRAME and FRAME
  requesting that @title be required (used by AT to identify FRAMEs
  and IFRAMEs to user) [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action02]

  [NEW] ACTION: Jim to review notification of existence of author
  context menu see bug 8682 [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action03]

  [NEW] ACTION: kford to look at longdesc issue with Gregory. Other
  also indicating they will look. [recorded in
  http://www.w3.org/2010/09/09-ua-minutes.html#action01]

  [End of minutes]
    _________________________________________________________
 
Received on Thursday, 9 September 2010 19:18:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 9 September 2010 19:18:11 GMT