- From: Martin Kliehm <martin.kliehm@namics.com>
- Date: Thu, 23 Sep 2010 18:16:43 +0200
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Minutes: http://www.w3.org/2010/09/23-html-a11y-minutes.html
IRC log: http://www.w3.org/2010/09/23-html-a11y-irc
====
- DRAFT -
HTML Accessibility Task Force Telecon
23 September 2010
Attendees
Present:
Eric_Carlson, Everett_Zufelt, Gez, Gregory_Rosmaita, Janina,
John_Foliot, Michael_Cooper, Rich_Schwerdtfeger, jongund, kliehm,
Paul_Cotton, Mike_Smith, Cynthia_Shelly, Adrian, Frank_Oliver
Regrets:
Aurelien_Levy, Kenny_Johar, Silvia_Pfeiffer, Marco_Ranon,
Laura_Carlson, Denis_Boudreau
Chair:
Janina_Sajka
Scribe:
Martin_Kliehm
Contents
Topics
1. Keyboard Access Requirements
2. Drag & Drap
<scribe> scribe:Martin_Kliehm
<janina> Meeting: HTML-A11Y telecon
<janina> Chair: Janina_Sajka
<janina> agenda: this
<scribe> scribenick: kliehm
TOPIC: Keyboard Access Requirements
Janina: Discussed keyboard accessibility yesterday, will be on the
agenda at UA telcon later
Gregory: Taking accesskey from HTML4 and logging bugs against HTML5 to
restore and improve functionality.
Gregory: Working with the UAAG WG, keyboard is just a one device for
device independence. Checked against WCAG 2.0 if everything is already
in HTML5 and if HTML4 has been imported.
Gregory: With Léonie will write up the requirements for the element
formerly known as accesskey until next week.
John: need help?
Gregory: will get back to you and other people for feedback.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access/pf_requirements
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements
Janina: If we need to set-up a telcon we'll do this. The goal needs to
have bugs filed by October 1st.
Gregory: (answering use cases question) some WCAG 2.0 techniques have
explanatory notes, there's also discussion on PF requirements.
<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access
Gregory: Work is required to restore functionality that used to be in
HTML4 in HTML5, also new functionality is yet underspecified. For
example a case of multiple access keys where a pseudo-cascade exists.
<oedipus>
http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements
<JF> JF suggests we move this to the list
Jon Gunderson: use cases will help implementors to understand better
when accesskeys will be useful.
<oedipus> GJR: thinks there is enough work to do filing the bugs --
don't know if ad-hoc would really help
<oedipus> GJR: would rather have side-skype chats as necessary
<JF> +1 greg
<oedipus> problems with accesskey-as-is in HTML5:
http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/access_key_requirements
TOPIC: Drag & Drap
Gez: Wrote an email last week
http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0446.html
<Gez> http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0444.html
Gez: Everett suggested a great suggestion...
Everett: The event model is robust. Gez identified problems with the
workflow and the order of events being fired during drag & drop. I
mapped those events to a keyboard scenario.
<oedipus> GJR: still maintains that drag and drop is copy-and-paste /
cut-and-paste for non-mouse non-visual users
Everett: Screenreaders need a list of draggable items and available
dropboxes through a menu.
... would be helpful to have an attribute for drop target or dropable.
<oedipus> drag and drop proposal:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0410.html
Rich: We have all that in ARIA: aria-grab set to false means it's
draggable, true means it's being dragged.
<oedipus> martin on drag and drop next steps:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0440.html
Everett: My preference would be not to use ARIA because it's attaching
an external resource instead of having it natively in HTML5.
Rich: ARIA is part of HTML5.
Greg: We'd like to follow the ARIA workflow but have accessible drag and
drop as a native aspect of HTML5.
John G.: There's a difference for an author between making an item
focusable while a list of draggable objects would remove that burden
from the author.
<oedipus> EZ: list - as move through list, events fire
<oedipus> RS: you want a list of droptargets - user navigate through
list to do drop -- will you be able to provide sufficient contextual
info for user?
Everett: expect user agent to generate a list of draggable objects and
drop targets. An author would still need to identify the elements.
<Zakim> oedipus, you wanted to ask if we need to restore a copy and
paste API into HTML5?
Everett: for complex lists a title or an aria-label could provide
additional information, but for screenreader users it's not an easy
task. We'll need to do our best.
<oedipus> right, it is a circumscribed copy/cut and paste
Greg: Is the equivalent of drag and drop comparable to copy and paste?
Everett: It's different since drag & drop has a list of drop targets.
Rich: Screenreaders have a lot of information of contextual information
that would be lost if the UA just displays a simple menu list.
Everett: A UA could provide more contextual content when the user
requests it with keys.
<oedipus> extended meta data queries need to be built into ATs,
especially screen readers
<oedipus> keyboard events in DOM3:
http://www.w3.org/TR/2010/WD-DOM-Level-3-Events-20100907/#events-keyboardevents
Adrian: Came to pretty much the same conclusion as Everett. Don't see
much work on the vendor site. Just need a list of enumerated items of
drop targets. With event bubbling it's unclear where an object could be
dropped, defining a drop target would help.
Janina: What have we missed?
Greg: Drag & drop could be seen as a limited copy & paste API where the
available drop targets is limited.
Rich: List of drop targets is important, but I'd take the other things
into consideration as well. Like going to one drop target and easily
moving to the next.
<oedipus> under the section 5.3 "Drag and Drop" there used to appear
section 5.3.5. "Copy and Paste" reproduced below:
http://www.w3.org/TR/2008/WD-html5-20080122/#copy-and
Jon Gunderson: What's keeping an author from defining the whole document
as droppable?
Everett: Can't keep an author from it, but it wouldn't be according to
the spec.
<oedipus> paste from selection (copy and paste portion of old draft's
section on DnD: http://www.w3.org/TR/2008/WD-html5-20080122/#paste0
<oedipus> GJR will put all this info onlist in an email
<oedipus> "Copy-and-paste is a form of drag-and-drop: the "copy" part is
equivalent to dragging content to another application (the "clipboard"),
and the "paste" part is equivalent to dragging content from another
application. "
Jon: Event delegation is important for author for performance reasons.
<oedipus> amen to steve - a LOT of keyboard navigators don't use AT
<oedipus> JS: AT is a "last resort" there are a lot of people who need
keyboard support and native support because don't rely on AT
Everett: Limiting the number of events being fired would increase
performance more than setting a number of event listeners.
<JF> +1 with Steve. File the bugs, back-fill later
<JF> +q
<oedipus> dnd proposal:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0410.html
Everett: suggesting to file a bug saying the spec needs to be less
device specific or provide additional examples.
<oedipus> next steps on dnd from kliehm:
http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0440.html
<richardschwerdtfe>
http://lists.w3.org/Archives/Public/www-dom/2010JulSep/att-0106/UserInterfaceIndependence.html
Everett: The terminology could be improved because "drag" is not device
independent, could be more agnostic.
<oedipus> JF, no the copy and paste API that used to be in HTML5 but was
removed
John F.: Let's get the bugs in even if they are not fully fleshed out
Janina: Who's filing the bugs?
Gez will file the bugs.
Janina: Concern from facilitators that we're losing minutes. Please keep
quality up so that we're able to track progress.
<oedipus> copy and paste section of HTML5's drag and drop no longer in
spec http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0525.html
<JF> Greg, your email came through to the list
Janina: Thanks everyone.
Received on Thursday, 23 September 2010 16:17:41 UTC