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

I have added some potential uses of the "Access" command to the wiki:

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


Let me know if this is the type of functionality you think the access commands should have.

Jon


Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61820

Voice: (217) 244-5870

WWW: http://www.cita.illinois.edu/


---------------------------------------------------------------
Privacy Information
---------------------------------------------------------------
This email (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. It is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this email is not the intended recipient, or agent responsible for delivering or copying of this communication, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please reply to the sender that you have received the message in error, then delete it. Thank you.


-----Original Message-----
From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Martin Kliehm
Sent: Thursday, September 23, 2010 11:17 AM
To: HTML Accessibility Task Force
Subject: Minutes for HTML-Accessibility Task Force Telephone Conference on 23 September 2010

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 18:57:13 UTC