HTML-A11Y telecon -- 16 Sep 2010

<janina> agenda: this

<JF> I've muted at my end

<kliehm> http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List

<inserted> scribenick: jongund

<inserted> scribe: Jon_Gunderson

Access-asterisk (requirements for accesskey in HTML5)

JS: Accesskeys is the topic
... We would like to do more than just get status
... We need to meet the October 1st deadline
... Media group may need one more meeting
... We have two areas we have not had the movement in to areas, where we need bugs filed

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Access

<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

<oedipus> problems with accesskey as-is in HTML5: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0103.html

<oedipus> chaals' analysis of GJR"s "problems with accesskey as-is in HTML5: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0159.html

<oedipus> paulC suggested that these be entered as individual bugs: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0119.html

JS: The on of the issues is keyboard access or device indepdence

<oedipus> judyB suggested that the TF discuss them first: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0149.html

<oedipus> verbose descriptor requirements: http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0436.html

<oedipus> 2 acceskey bugs filed:

<oedipus> 1. [Bug 10251] Psuedo-Cascade of Multiple Accesskeys Definable for an Individual Element: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10251

<oedipus> 2. [Bug 10252] New: HTML5 hard-binds "Action" to accesskey key-press: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10252

JS: The other issue is drag and drop device independence, so AT can perform drag and drop, current implementations are mouse centric
... Let's access command first and then move to drag and drop

<oedipus> UAAG dependencies and access-* http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

GR: Accesskey was not a part of HTML5 it has now been reintroduced
... The user agent group is a

I am muted now

GR: ... Originally HTML5 did not have accesskey, so PF submitted requirements and then nothing seems to have been done

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Talk:Access/pf_requirements

GR: HTML5 has introduced accesskey, but does not seem to address the accessibility issues
... I looked at UAAG 2.0 and I put on the wiki pages, see URI
... There point of view is very keyboard centric, I would like to see more device independent, I think we want to fill the holes of discoverability and device independent activation
... I am looking at UAAG 2.0 requirements for conformance
... Listed a number of commands ....
... The UAAG meets in an hours time, I will bring back more feedback from them

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

GR: GR: Any questions?

CS: SO on some other items, doing no hard, and then attempting to make improvements past that?

GR: That is a good question and I pose it to the task force
... I have been thinkig of taking HTML4 implementation and then addressing the problems and getting spec ready text

JF: Comment on problems with HTML5

GR: I want to take the proposal to UAAG and then come up with spec ready text, I think we need something they can plug right in

<JF> +Q

CS: I think we need to be ready for changes and take anything missing in HTML4 in HTML5

GR: I will put in bugs related to moving focus and discoverability

CS: Is the work item?

GR: Put back what is no longer in HTML5
... Add verbage satisfies the task for requirements

CS: Make sure it is clear int he bug tracker

GR: I am hoping by this effort I can identify problems with tabindex and command element ....

CS: That seems reasonable...
... Don't get upset if the bugs get pushed out

GR: The task force will be tracking these issues

JF: You mention spec ready text we need a change proposal, do we need to discuss here

<MikeSmith> yes, bugs

GR: We discussed this briefly last week, mike says lodge things as bugs, because issues are hard to now

CS: Ian will want to work on bugs

<MikeSmith> the chairs will also ask for separate specific bugs to be filed

GR: I will be doing both, I will put in bugs and develop spec ready text

CS: Make sure you make as HTML4 feature or new feature in HTML5

<MikeSmith> w00t oedipus

JF: Thank you to GR from everybody

JS: I agree we are behind his efforts

Drag and Drop

JS: We have some developers here
... Can you give us a summary

??: I had a look at the drag and drop section

WHo is speaking?

<oedipus> GJR's synopsis of where we are with HTML5 DnD versus ARIA Dnd http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0410.html

GL: The series of events are mouse based
... It is difficult to understand how to do this on the keyboard??
... Do the event processing need to be revised to support the keyboard \, like ARIA

<oedipus> ACTION: Gregory - prepare detailed bugs against accesskey in HTML5, bugs seeking restoration of elements of accesskey from HTML4 that work and are deployed; will identify clearly whether bug refers to HTML4 or HTML5; in preparation for preparing spec ready text for accesskey; will tease out the issues pertaining to @tabindex and COMMAND element [recorded in http://www.w3.org/2010/09/16-html-a11y-minutes.html#action01]

<trackbot> Created ACTION-62 - - prepare detailed bugs against accesskey in HTML5, bugs seeking restoration of elements of accesskey from HTML4 that work and are deployed; will identify clearly whether bug refers to HTML4 or HTML5; in preparation for preparing spec ready text for accesskey; will tease out the issues pertaining to @tabindex and COMMAND element [on Gregory Rosmaita - due 2010-09-23].

GL: Something similar to ARIA with grabbable and drop targets

JF: The copy paste model seems to make more sense

CS: Does the developer need to write extra code

<oedipus> To make drag and drop accessible, HTML5 must:

<oedipus> * first adequately define what can be achieved via copy and paste using drag and drop;

JF: Yu should be able to identify target with HTML5

<oedipus> * define a copy and paste API in order to make drag and drop accessible; if that is not a viable solution, then the HTML5 drag and drop API MUST be amended to allow the workflow suggested for drag and drop in the WAI-ARIA Authoring Practices document: http://www.w3.org/TR/wai-aria-practices/#dragdrop

CS: Work is int he browser?

<oedipus> * first adequately define what can be achieved via copy and paste using drag and drop;

GL: Yes in the browser

JS: Do you folks have any reaction to this?

<MikeSmith> janina, Adrian Bateman is on as well

JS: We have this working for mouse and non-mouse controllers

<oedipus> JCraig indicated that the ICITA ARIA DnD examples didn't work "normally" but work for me with JAWS 11/12

AB: The events in the spec provide 2 different things, source and target
... The second is providing feedback during the drag

<oedipus> AB, http://www.w3.org/TR/wai-aria-practices/#dragdrop

AB: Is the spec sufficient for providing information about drag and drop, is there something missing, is that the gap?

GL: Part of the sequence it povides feedback when you drag over with the mouse

AB: Is the gap is how to enumerate the drop targets?

GL: Yes

<oedipus> next steps on drag and drop (Gez) http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0056.html

AB: The order of events are different, some are dependent on how fast you move the mouse

<oedipus> AB, there is no longer a copy and paste API in HTML5

AB: The real critical thing, comparing to copy and paste model, is the spec sufficient or does there need to be changes

GL: When these events fire, there need to be equivalent keyboard events

GL It is only one solution, so maybe it could be simulated in a copy and paste API

<oedipus> AB, would have to either reinstate copy and paste API or have HTML5 follow the ARIA DnD workflow http://www.w3.org/TR/wai-aria-practices/#dragdrop

GL: We don't want to have two apis

AB: Is is possible the spec provides enough information for the user agent to provide copy and paste functionality

<oedipus> GJR has long believed that keyboard drag and drop is a copy-and-past or cut-and-paste operation

AB: If we have all we need, no change is needed

GL: I don't know the answer

AB: We need to find the answer to that question

<kliehm> AB, the drag & drop event model does not seem to be very consistent from a JavaScript author's point of view.

GL: My gut feeling is there will need to be changes to the spec, we need someone from the browser side to review

<oedipus> the only mention of copy and paste found in dev.w3.org/html5 is an example included in the introduction to the MENU element: http://dev.w3.org/html5/spec/interactive-elements.html#menus-intro which illustrates how to use the MENU element to create a toolbar styled as buttons with drop-down menues, in which the "Edit" button contains a "Copy" and a "Paste" item, controlled by javascript

JS: To move forward on this so need people to walk the events in different orders

GR: The only reference to copy and paste has only one reference and the the API seems to have been removed

JS: How do move forward to answering the question

<MikeSmith> yes, the copy-and-paste section that was there is not there any longer

GL: I would be willing to work with adrian, I can't do myself

Frank: I think we can help

JS: That is a reasonable step, if you can do that we can get any bugs in by October 1st

<kliehm> I found that one: http://dev.w3.org/html5/spec/dnd.html

JS: Are we satitisfied?

<JF> +1

GR: I think GL has done his due diligence, I think it is a good way to move forward

<oedipus> plus 1 and big thanks to gez

JS: Thank you Frank and Adrian for joining the meeting today
... We will come back to it next week, hopefully we will have some more clarity, we need to log bugs by October 1st

Actions review and sub team status

MC: Reviewing open action items

GR: That text has been up there since june, I want to potentially use the space to mark them for stuff that needs to be in steves done
... It is techically done, but I need to talk to steve

CS: That was a huge battle, is it going to happen

JS: Issue 66 was turned down, image hueristics

MC: This action is open or closed state?

JS: I think we should close it

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Alt_tech_appendix

JS: Probably open a new action

<MichaelC> close action-28

<trackbot> ACTION-28 - prepare text for SteveF's guidance document about future of data-mining using RDFPic methodology outlined in post to list closed

MC: Any objection?

GR: No

MC: Auto complete consistent with ARIA?

JS: Steve is not here

MC: Provide back ground support for drag and drop?

<MichaelC> close action-57

<trackbot> ACTION-57 Provide background keyboard support for drag and drop (3 weeks) closed

JS: I think this has been overcome by events, now that GL and AB are connected
... Close

MC: Action 58 can anyone post to HTML list?

JS: Still open

<oedipus> action-58?

<trackbot> ACTION-58 -- Michael(tm) Smith to - ascertain if can allow posting to public-html-a11y by anyone subscribed to public-html -- due 2010-09-16 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/HTML/track/actions/58

<MichaelC> action-58: duplicate of action-59

<trackbot> ACTION-58 - ascertain if can allow posting to public-html-a11y by anyone subscribed to public-html notes added

<MichaelC> close action-58

<trackbot> ACTION-58 - ascertain if can allow posting to public-html-a11y by anyone subscribed to public-html closed

JS: Sounds like a duplicate, so we will keep 59

<oedipus> action-59?

<trackbot> ACTION-59 -- Michael(tm) Smith to check into making it possible for any HTML WG member to post to the a11y TF list -- due 2010-09-16 -- OPEN

<trackbot> http://www.w3.org/WAI/PF/HTML/track/actions/59

MC: The next 3 actions are not due yet

JS: Tahnk you

SubTeam reports

JS: Martin will be the chair

<JF> +1 with oedipus

JS: Is there any update beyond the leadership?

MK: So on this weeks 8 ..., discussed them and MC made updated them

<oedipus> [BUGS] Minutes of the HTML Accessibility TF Bug Triage Sub-Team, 14 September 2010 Martin Kliehm) http://lists.w3.org/Archives/Public/public-html-a11y/2010Sep/0409.html

MK: We will be doing home work for info box
... The bug triage team is trying to keep up with the bug filling, I will try recruiting more people at a conference next week
... There will be more people

JS: Wunderful, october is not that far away

MK: Meetings are on tuesdays

JS: This is great, people have been asking about participation

MK: We have some technical constraints of two lines from UK, we have more people from UK

JS: That is a problem for all people in W3C, W3C needs to get more lines
... We do have high European participation on the team

CS: It is a hard time for me to come at that time, but I will try to come

<JF> JF offers to buy Cyns coffee

CS: I will try to get there every other week

JS: What other groups need some direction from the TF
... ARIA sub mapping??

CS: We met Tuesday and Ian asked for individual bugs and we have gone through the bugs to see what is fixed
... We have an early draft or ARIA to HTML5 mapping, trying to get it into W3C space, so we have something to share as bugs are closed
... We can use more people

<Stevef> maciej sent out update today: on ARIA bugs: http://lists.w3.org/Archives/Public/public-html/2010Sep/0189.html

JS: The blank page is the toughest part

CS: The hard part is figuring our what other info is needed

JS: Questions?

<Stevef> i sent out minor update: http://lists.w3.org/Archives/Public/public-html/2010Sep/0190.html

<oedipus> CYA change proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/restore4a11y

JS: CANVAS update

<oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Canvas

JS: We had made recommendation, a more generic solution was suggested, which would include the default situation, we decided it was quicksand
... Something that is additional work, it is beyond the accessibility work, we decided at our coordination meetings, and the chairs will back up to issue 74
... Include the image map proposal from CMN
... Media group is working on how to take the features and move them into technology recommendations

JF: We are trying to map the requirements to WCAG 2.0 requirements, developing a must, should, may effort
... We should have a detailed report

JS: Thank you everybody's help, your work is appreciated

<oedipus> scribe: Jon_Gunderson

- DRAFT -

HTML-A11Y telecon

16 Sep 2010

Attendees

Contents

Access-asterisk (requirements for accesskey in HTML5)

Drag and Drop

Actions review and sub team status

SubTeam reports

Summary of Action Items

Scribe.perl diagnostic output