<scribe> scribe:Martin_Kliehm

<janina> Meeting: HTML-A11Y telecon

<janina> Chair: Janina_Sajka

<janina> agenda: this

<scribe> scribenick: kliehm

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.

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

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.

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.