See also: IRC log
<scribe> scribe:Martin_Kliehm
<janina> Meeting: HTML-A11Y telecon
<janina> Chair: Janina_Sajka
<janina> agenda: this
<scribe> scribenick: kliehm
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.
s/Gergory./Gregory:/
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
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.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/maybe he needs a scribe first?// Succeeded: s/I don't hear anyone on// Succeeded: s/I made mine extra strong today// Succeeded: s/scribenic:kliehm/scribenick: kliehm/ FAILED: s/Gergory./Gregory:/ Succeeded: s/feedack/feedback/ Succeeded: s/filed bugs/bugs filed/ Succeeded: s/Answering use cases:/(answering use cases question)/ Succeeded: s/John: use cases/John Gunderson: use cases/ Succeeded: s/John Gunderson/Jon Gunderson/ Succeeded: s/follow the ARIA workflow/follow the ARIA workflow but have accessible drag and drop as a native aspect of HTML5/ Succeeded: s/object has been dropped/object could be dropped/ Succeeded: s/don't rely on ATY/don't rely on AT/ Succeeded: s/Rich: The terminology/Everett: The terminology/ Succeeded: s/Gez?/Gez will file the bugs./ Found Scribe: Martin_Kliehm Found ScribeNick: kliehm WARNING: Replacing list of attendees. Old list: Rich_Schwerdtfeger Janina Gregory_Rosmaita John_Foliot Eric_Carlson Michael_Cooper Everett_Zufelt kliehm Gez jongund adrianba Mike Cynthia_Shelly [Microsoft] franko Steve_Faulkner New list: Rich_Schwerdtfeger Janina Gregory_Rosmaita John_Foliot Eric_Carlson Michael_Cooper Everett_Zufelt kliehm Gez jongund Default Present: Rich_Schwerdtfeger, Janina, Gregory_Rosmaita, John_Foliot, Eric_Carlson, Michael_Cooper, Everett_Zufelt, kliehm, Gez, jongund 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 Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0499.html Got date from IRC log name: 23 Sep 2010 Guessing minutes URL: http://www.w3.org/2010/09/23-html-a11y-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]