HTML Accessibility Task Force Teleconference -- 08 Jul 2010

<JF> we should have a meta discussion regarding the general principle of splitting out authoring guidance from the larger spec, especially when it impacts on accessibility issues.

muted myself

<JF> This is currently an active topic regarding Issue 31 [1] versus SteveF’s First Public Draft regarding @alt text [2] (with an indication that Ian will be submitting a null change proposal for Issue 31 [3]) and also related to Action Item 44 [4] (as well as possibly Item 46 [5]). Establishing a general principle (Resolution?) within the TF on this issue will become important (IMHO). I also...

<JF> ...anticipate that this issue will likely re-surface with ongoing work within the media sub-team’s current activities, so a clearly articulated position will be import there as well.

<JF> [1] http://www.w3.org/html/wg/tracker/issues/31

<JF> [2] http://www.w3.org/TR/2010/WD-html-alt-techniques-20100624/

<JF> [3] http://lists.w3.org/Archives/Public/public-html/2010Jul/0000.html

<JF> [4] http://www.w3.org/WAI/PF/HTML/track/actions/44

<JF> [5] http://www.w3.org/WAI/PF/HTML/track/actions/46

Media team; status on requirements; next steps

JF: we have a number of comments devided up among different takers. Divided in two batches.
... first batch done last week, second will be done by the end of this week
... by next week the requirements doc will be ready and we'll start working soon on tech requirements

MS: we are on schedule. anything blocking?

JF: most issues resolved.

MS: what after the requirements doc is ready?

JF: javascript API needs to be moved forward
... make sure tech specs follow the requirements and address all issues.
... I believe we are getting close. Maybe a week / 10 days
... move on

ARIA team; ARIA-in-HTML conformance spec text

MS: Cynthia?

CS: submitted to WG with small tweaks.

general principle of splitting out authoring guidance (John Foliot)

JF: with Steve's doc we are starting to split guidance from the specs

<MikeSmith> Agenda Item for next week's a11yTF Conference Call?

JF: this will be important with media. the TF shuold push towards having a guidance document

MS: examples?

JF: authoring transcripts, captions, subtitles

MS: two options: JF to drive it or somebody else? Indicating what to have in a separate document.
... JF, can you put some more time on this or anybody else can take responsability for it?

<Zakim> MichaelC, you wanted to note that, related to timeline discussion, we need to focus resources on on-time core deliverables, then turn attention to auxiliary work

JF: is there agreement in the WG / TF that this is the way forward?

CS: I agree that we shoulld break down things in different documents

MC: we need to concentrate on timeline first and optimise resources
... important work but not right now

<dboudreau> I believe that breaking things down in different docuemnts is a good idea as well

+ 1

JF: the TF should decide if splitting things is the best way forward?

CS: authors won't read the specs

<oedipus> there is a queue

<dboudreau> having documents on the side that can evolve once html5 is set in stone can only be a good way forward as far as i'm concerned

JF: the guidance document could evolve, the specs stay fixed

<Zakim> oedipus, you wanted to ask to what degree do we want to go down this road -- a document for proper TABLE markup seems far less useful than putting info into HTML5 spec

<dboudreau> most authors i know will read techniques documents, but very few go down the specs themselves

Gregory: to what level do we want to break down the docs?

<dboudreau> isn't there a way for us to set the foundations in the spec, but refering to document techniques for details? Most people aren't lazy, theyr'e just afraid of the larger documents... and html5 is already huge

GR: a bit concerned about to much splitting out
... we need to protect the specs

JF: the specs should only to deal with the markup and not the discussion

<oedipus> dboudreau, understood - it needs to be in both places, and mutually reinforced

PC: why should we split the material?

JF: by splitting these document we would provide examples that are not strictly tech specs

<oedipus> dboudreau, i like the "markup spec" version because it doesn't crash my UAs like the "main" HTML5 spec often does

<dboudreau> because the main spec is much too big?

<oedipus> dboudreau, precisely

PC: not talking about taking accessibility issues off the html specs?

JF: no

<oedipus> GJR perceives need to distinguish between the science and the art of accessibility -- where "art" means how to provide terse and long descriptors, but the nuts and bolts for accessibility should not only be in HTML5 spec, but in EVERY example therein

<dboudreau> oedipus, the same thing would have happened in wcag 2, had the techniques and failures been integrated directly in the spec

JF: we still have to decide if we want to follow this principle

PC: i think the current html5 specs are adequate to authors, and i wonder if splitting docs would be really helpful

<dboudreau> aren't we on the path of splitting documents to have one for UA and one for authors?

GJR: we need to distingue between the science and the art of accessibility.

GRJ: access principle should always be part if the specs, implementations should e in a separate document

PC: discussion to be contuined on the mailing list

<oedipus> dboudreau, i'm not sure what cowpath we are on ;)

<oedipus> GJR notes that aria drag'n'drop is supported in the latest point release of JAWS 11 (as is verbosity control over live regions)

any progress on ensuring that drag-and-drop events are keyboard activatable?

<dboudreau> oedipus :) for the record I agree with what you'Re saying... the principles should be in the spec, but not the implementation

MS: any new information on DnD?

GJR: Jaws 11 has support for DnD and live regions

<oedipus> http://www.freedomscientific.com/downloads/jaws/JAWS-whats-new.asp

<oedipus> previous link contains info about JAWS support for ARIA drag'n'drop and live region control

bug triage

<MikeSmith> Weekly Resolved & Rejected Bugs Report

<MikeSmith> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10026

MS: Bug 10066: waiting for editor response.
... Volunteers? maybe Joshue O'Connor?
... Bug 9657: please respond to Lief

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

<MikeSmith> CAPTCHA bug

MS: CAPTCHA BUG
... do we need a survey about CAPTCHA?

MC: we can do a survey.

<dboudreau> Captcha survey: I'd say give ppl time to go over it again then decide if it's rdy for publication

MS to talk to MC offline

<oedipus> captcha example in HTML5 thread: http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/thread.html#msg361

<MikeSmith> http://www.w3.org/WAI/PF/HTML/wiki/Bugs/Bugs_Awaiting_A11yTF_Keyword_Decision

MS: please add comments and send messages to TF mailing list if yuo feel strong about any of the bugs

Review open action items

<MikeSmith> Open Actions

MS: not time left for all actions

<MikeSmith> action-28?

<trackbot> ACTION-28 -- Gregory Rosmaita to - prepare text for SteveF's guidance document about future of data-mining using RDFPic methodology outlined in post to list -- due 2010-07-01 -- OPEN

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

GJR: next week for action 28

<MikeSmith> action-28 due 2010-07-15

<trackbot> ACTION-28 - prepare text for SteveF's guidance document about future of data-mining using RDFPic methodology outlined in post to list due date now 2010-07-15

<MikeSmith> [ajourned]

regrets for nex week from me

<dboudreau> ok take care all

- DRAFT -

HTML Accessibility Task Force Teleconference

08 Jul 2010

Attendees

Contents

Identify scribe

Do once-over of previous meeting minutes