- 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