W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2010

Minutes for HTML-Accessibility Task Force Telephone Conference on 23 September 2010

From: Martin Kliehm <martin.kliehm@namics.com>
Date: Thu, 23 Sep 2010 18:16:43 +0200
Message-ID: <4C9B7D6B.8060201@namics.com>
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



HTML Accessibility Task Force Telecon
23 September 2010


     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

     Aurelien_Levy, Kenny_Johar, Silvia_Pfeiffer, Marco_Ranon, 
Laura_Carlson, Denis_Boudreau




    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.


<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: 

TOPIC: Drag & Drap

Gez: Wrote an email last week 

<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: 

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: 

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: 

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: 

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: 

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: 


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 

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:44 UTC