Protocols and Formats Working Group Teleconference -- 03 Nov 2009

<trackbot> Date: 03 November 2009

<richardschwerdtfe> otay

<richardschwerdtfe> Hi Sally

<richardschwerdtfe> Hi Loretta

<richardschwerdtfe> what is the scribing rotation?

<richardschwerdtfe> Hi Laura

<Laura> Hi

<jcraig> Zaim, who is on the phone?

<richardschwerdtfe> I will scribe if you like

<inserted> scribenick: richardschwerdtfe

<scribe> scribe: Rich

PF view of the HTML specifications

Michael: So far our review has been adhoc

<MichaelC> --> http://www.w3.org/2009/08/html5-spec-review PF HTML spec review draft

Michael: What I am projecting on the screen is the HTML spec review
... We broke out the HTML TOC and spread out among reviewers
... The first column shows the TOC for review
... The second column is who has reviewed
... Third column blanks means nothing has been reviewed
... There are lots of blank sections on the screen still
... Most work has been done by one person
... I would like greater participation
... I have copied the entire TOC and subsections
... we do have a number of comments throughout the spec.
... I have tried to identify the reviewer to know who to ask
... we should go through the comments received
... Should we talk about the overlay on the HTML spec. process
... this is not a formal process but more something we would like to do

<MichaelC> --> http://www.w3.org/WAI/PF/wiki/Process_to_submit_HTML_spec_comments PF's proposed overlay on HTML issue process

PF's proposed overlay on HTML issue process

Michael: add keyword a11y to the issue. You need keyword access via bugzilla
... If the working would like to have it be a formal comment it would be PFWG as the key word

Paul: Adding keywords to bugzilla good

Janina: welcome Laura
... are there any questions or comments regarding the process?

I can't hear this person

Steve: have the UWAWG comments been folded in?

Michael: no not yet.

Judy: We have been having on going discussions with the wai-cg

thanks

Judy: in some of the cases the comments were reflective of what were already looked at

Michael: We can always add the PFWG keyword to comments later

Kelly: if you want UWAWG to do that please just tell us what to do

Janina: please tag as a11y

Laura: I went through a number of them but I am not sure I tagged them all

Michael: I have all the comments in our tracking page
... I feel it is stronger if submitted separately. We can just add our plus 1 to them

<Laura> a11y bugs: http://www.w3.org/Bugs/Public/buglist.cgi?product=HTML+WG&keywords=a11y

Paul: If you clearly state the problem and the proposed change the editor may just say done!
... It is very possible that if you provide a change that identifies a problem and a change it just may be applied

<MichaelC> --> http://dev.w3.org/html5/decision-policy/decision-policy.html HTML WG Decision Policy

Paul: You should not assume that it goes directly to the HTML working group just because you enter a problem in bugzilla
... We expects hundreds or thousands of problems logged on HTML 5
... You can get a response from the editor. You need to decide if you agree or not.
... If you don't agree to an editors change on your bug or another's you can escalate to the working group

Janina: The key here is sending email to the email list

Paul: Does everyone understand why we are doing this?
... The W3C process is pretty liberal. The chairs took on the responsibility of taking putting a procedure in place

<Laura> Process for Bugs and Issues

<Laura> http://esw.w3.org/topic/PF/XTech/HTML5#head-b8f7f2d5391d0eade067cdacbb9592a9dcbf8b1c

Paul: we need the process document to take to the director
... When we issue a last call draft for HTML 5 we will get a huge amount of comments, and that will generate a lot of work for us
... So, we need solid consensus within the working group

<Laura> Writing a Change Proposal

Paul: there has been a feeling that the only way to change the document is to edit it

<Laura> http://dev.w3.org/html5/decision-policy/decision-policy.html#escalation-step-2b

Paul: that is not the case

Janina: when HTML 5 goes to last call it is important to have our own tracking list
... PF will sign to initiating some of these

<jcraig> so use the 'a11y' keyword in bugzilla

Janina: we are trying to have a mechanism to meet the HTML working group's process and our needs

Judy: Janina, at some point I would like to give a brief update from last night

Steve: drag and drop keyboard accessibility is already a semi-active bug

Michael: When you enter a bug does it refer to a section of the spec. that it corresponds to?

Paul: I would not worry about duplicate bugs
... you can be sure that the receiving groups will correlate bugs
... you should react to that by going to the oldest bug
... the comment may include your opinion on that bug
... I would not spend time worrying about a duplicate

James: in my opinion file the bug vs. risking missing one

Janina: any further process questions?
... we should confer with other groups that may be filing bugs

Kelly: The WAI CG group should produce a document on how HTML 5 bugs should be handled

Janina: Hasn't Michael started this?

Michael: That is what I have on the screen now
... We have not announced this as we hashed it out on a caucus call

RESOLUTION: PF has approved the new process for submitting HTML bugs

<jcraig> http://www.w3.org/WAI/PF/wiki/Process_to_submit_HTML_spec_comments

<MichaelC> --> http://www.w3.org/WAI/PF/wiki/Process_to_submit_HTML_spec_comments PF's proposed overlay on HTML issue process

Kelly: Let's say that UAAG files a bug and HTML 5 does something with it that UAAG or someone else does not like?
... who is the champion?

James: depending on the issue, it may be most appropriate for the group that raises it to follow up

Michael: the submitter will get copies

Janina: our intention is to monitor issues tagged with a11y but not with pf (or pfwg?) as a way to catch issues we may not be aware of

Michael: I suspect this will become a wai CG discussion topic

Kelly: I just want the html 5 task force to have some oversight responsibility

Rich: I think there should be some oversight in the task force to ensure these issues are addressed

Michael: The task force may agree with the escalation but the submitter should follow through

Paul: for any issues that somebody has related to accessibility the issue can be assigned to the task force. This is the heart of Steve's question
... we don't have process for that now
... The so-called facilitators
... we will discuss the facilitator issue at 11 today

WAI CG discussion with HTML working group chairs and PF chairs

Judy: we don't have a facilitator from the HTML WG
... WAI believe that a co-led task force is needed to reach consensus
... we need a way to speed up WAI responses such as the mapping of ARIA features to HTML 5 features
... the importance of rapid communication into the HTML issues list
... so, coming back to the wai-aria mapping for low hanging fruit to ensure time to complete the mapping
... It does not need to be completed so we need to show where we are on it to show progress and where we might be stuck
... 5 action items

<Laura> Open Issues: http://esw.w3.org/topic/HTML/AccessibilityTrackerIssues#head-296f0770d95b88abd5898f852b48cc771cf52b7c

- form task force and find co-facilitator

- engage participants

- get wai-aria mapping done quickly

- get issues identified

- a joint action item to identify developers to help with HTML 5 implementations

Judy: it was an opportunity for better communication
... I would like to encourage more chair to chair communication

Paul: I think that is a fine summary

Rich: do we have a browser that supports all the HTML 5 constructs?

Paul: we are trying to find a way to engage the WhatWg. ... we are talking about browser implementation support
... some of are talking about how features got into HTML 5
... What we really need is not just a theoretical issue

judy: there was emphasis that we did not know that people were waiting so urgently on something
... there is an opportunity for better communication

Paul: the challenge is to get the what wg involved
... is there any way we can emphasize that here is an early prototype

Rich: I think there are logistical issues with working with say IE that does not share what is going into IE9

Judy: when I went over the action items for last night this is one that is a shared item

Sam: I would like to focus on pushing this down

Judy: the communication issue regarding what is implemented already is good

Sam: Maciej alone is not sufficient

Rich: the canvas example was posted to the public canvas api working group a week ago

<jcraig> [Offline to meet with MMI WG. We'll be back after that meeting.]

is anyone taking minutes?

there is nothing here

<MichaelC> minutes are in #multimodal

thank you

Joint discussion with MMI

<MichaelC> minutes taken in multimodal channel, probably available at http://www.w3.org/2009/11/03-multimodal-minutes

<SCain> Scribe: SCain

JS: Need to go on record to say that certain html5 issues are very important to us

<richardschwerdtfe> has this meeting started yet

<richardschwerdtfe> ?

<richardschwerdtfe> thanks

CS: We need to come up with things for break out sessions in HTML5 WG
... I know we want to talk about html5 and aria mappings
... Canvas accessibility, summary, others?

SF: Not sure about summary

JC: Canvas accessibility definitely, though I won't be available that day.

JS: We want to make sure Rich can be dialled in on that

RS: All my info is posted to the canvas discussion

CS: If we want to talk about it we can pitch it
... Pitch a break out session?

RS: Not available Thursday and Friday

JC: The general idea has been discussed and we need to get specifics

RS: Please look at the proposal
... I have had some discussions with Alex that went out today
... We might have to provide for equivalent stuff for canvas too
...

CS: What should we pitch for Thursday?

RS: Do we know if Canvas is in or out of the spec?

FO: It has been moved to a separate spec

RS: Alex is looking at the shadow issue. Tabindex is a concern as it is usually rendered and what is the impact of this? Frank has created an example of a shadow DOM. Alex is working with them to expose the shadow DOM where we could add aria properties to.
... This is a multi-stage process. We may need accessibility API applied to objects. We may need to have alternative views, dependant on what the user asks for. We could through the API switch the view.

CS: In addition to that fallback we do need accessibility in the main content also

RS: Not sure if we have time to engineer an API for canvas

CS: If we have a breakout on Canvas we may need to discuss this.

FO: From my position we don't need new API's. Need some way for tools and checkers to see if it has been marked as accessible. Need some way of marking canvas.

CS: Run into this with plug-ins

SF: Are we assuming that for keyboard based accessibility it is encumbered on the developer to build that accessibility in

CS: that is one thing being discussed

KF: Have you thought about alternative method of activation?
... Voice input for example?

CS: We are still figuring that out. We could do something that exposes the elements in canvas to MSAA
... I would like to make it easier on developers

SF: New library out called MooArt. It is building widgets with Canvas

JC: Operating Systems have always had custom views. Canvas is just the custom view within HTML and therefore there is more responsibility on the author to 'hook up' the accessibility.

<richardschwerdtfe> As a general strategy, browsers like FF will need to consider having the accessibility object model a reflection of what is not visible for technologies like SVG and canvas. When I brought ARIA to W3C the intent was to leverage the existing visible DOM as it is very much like today's GUIs. This will support HTML markup for a very long time. Yet, SVG and canvas are different animals. Here, your model is more like a collection of drawing primitives. Our sol

<richardschwerdtfe> needs to be one where we either:

<richardschwerdtfe> 1. provides an accessibility tree (hidden as you point out) bound loosely to what is being drawn and makes use of ARIA 1.0

<richardschwerdtfe> 2. provides for an accessibility API bound to these objects (longer term). Will require an ARIA 2.0 approach allowing for customization

<richardschwerdtfe> 3. allows for equivalent alternative content

RS: Discussing what posted into IRC

CS: I am not sure we have to have the discussion about what canvas accessibility means now, but lets pitch the discussion for thursday/friday.

RS: We want to have a shadow DOM that can be bound to the UI, what are the keyboard issues? What about the ability to have alternative views?

CS: Shadow DOM vs direct API access

JC: Tabindex vs activedescendant
... Activedescendant will not solve all of the long term problems

CS: Uncomfortable about the shadow DOM

JC: Feel the same way about authors having direct access to the accessibility APIs

RS: How would you go about swapping views?

CS: We need to work with tools vendors and ATAG

<richardschwerdtfe> http://lists.w3.org/Archives/Public/public-canvas-api/2009OctDec/0024.html

RS: Equivalent alternatives are sometimes more usable

KF: But we would need it to be available

JS: What is the alternative? Accessibility issue alone will not keep Canvas out of HTML5

CS: Influencing developer behaviour
... Making it easier, automatic...

JC: the shadow DOM approach is not easy. Have javascript libraries implement

CS: Having a starting point is fine. Who will do the pitch?

FO: I am happy to do the pitch

RS: Please talk to me if you want to discuss anything

KF: The browser would change what it renders?

RS: Yes

KF: This would have implications for user agent guidelines. Please keep me informed.

JC: What rendering would change?

RS: If I wanted a text modality, you could put in a piechart and so I would want the equivalent text modality of that. This would then be rendered where the piechart was.
... Do it through browser prefs or screen reader

KF: There are big implications for user agent
... If this view is available, give it to me

JC: This is reasonable and falls within UAAG

RS: This is one example, SVG will be another. Let the user make the preference.

CS: Are there other things that we want to have breakout with html?

RS: Good time to have the discussion around mapping.

<kford> Just as an FYI, UAAG 2.0 is looking a fall back content. We likely need to think/expand some of this to address some of the newer technologies.

CS: Yes

<oedipus> deprecation of use of TABLE for layout, as BLOCKQUOTE was deprecated in HTML 4.01 for styleistic purposes

RS: How would you make drag and drop accessible. How do we approach that in the spec.

JS: Good topic for conversation.

CS: Do we have the people we need for that

JC: Need to be able to mark something for selection. Methods aren't set out to allow that.

CS: Rich not there or JC so anyone else?

<kford> For UAAG on alternatives, this is still rough and as I say needs to be expanded but see 3.1 of http://www.w3.org/WAI/UA/2009/ED-UAAG20-20090722/

JC: We could file this as a bug

JS: Then lets escalate it
... John are you planning to talk about the accessible media summit on Sunday?

JF: I can share my impressions of what came out of that day?

JS: Would like to have a conversation about raising that

CS: Anything else?

SC: Read GJR comment

JS: Put a bug in on that Gregory with an a11y keyword

JC: Could be a note in the spec, rather than a 'deprecation'?

CS: Mappings, Canvas Accessibility, Summary of Accessible Media/Video Accessibility

<richardschwerdtfe> back in an hour

JS: Break for lunch - back for 13.00 PT
... DAISY underestimated what they can bring to the table as regards accessible media

JF: Scalability is something we are always going to grapple with

JS: Requirements gathering will happen fast, make sure yours are in there
... There is a lot existing to borrow from
... I thought Sunday's meeting was an excellent start

Bugs to file on html5

JS: We need to file these things correctly within process
... Low hanging issues, Canvas
... We could move to flag it as something we care about
... Video, audio, alt for example

MC: In existing bugs for canvas there is one bug that has been bounced back
... Outlining issues closed and open for canvas
... Do we need to mark it as pfwg?

JS: any objection to identifying canvas?

RESOLUTION: Identify Canvas as an issue to be noted in Bugzilla

MC: Adding notes to the bugzilla formally as pfwg

<richardschwerdtfe> "public-canvas-api@w3.org" <public-canvas-api@w3.org>

JS: Are there bugs filed for video/auio?

MC: Bug 5758
... Tag this with pfwg

JS: Is there objection to putting pf on record?

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/Table/LayoutTABLEDeprecation

<oedipus> no

RESOLUTION: Identified <video> and <audio> as an issue of interest formally to pfwg

SF: Alt

<oedipus> accesskey replacement requirement?

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements

MC: Bug numbers for alt are 6494, 7362, 7144

<oedipus> accesskey currently a "dropped" feature of HTML5

<oedipus> tabindex also "dropped

MC: Issue 31 and Issue 66 in tracker

<oedipus> http://esw.w3.org/topic/HTML/DroppedAttributeAccesskey

<oedipus> http://esw.w3.org/topic/HTML/DroppedAttributeTabindex

SF: Outlining Bug 7362
... Question is around the algorithm

<oedipus> set a cascade - alt, title...

CS: Do nothing?

<oedipus> where is the current iteration of the algorithm?

<oedipus> :-(

<Zakim> oedipus, you wanted to ask where can one find the latest iteration of the algorithm?

GJR: Wanted to ask for latest iteration of the algorithm

<Stevef> http://www.w3.org/TR/html5/text-level-semantics.html#the-img-element

<Zakim> oedipus, you wanted to ask SF, what if there is a LEGEND or CAPTION?

<oedipus> does the algorithm allow for binding of multiple images as in the 3 stages of a butterfly's life?

SF: Then it is used

JS: Lets avoid weeds and formally get behind WAI consensus document

SF: Issues with consensus document that have been discussed in html WG

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/MediaSpecificElements

<Laura> http://www.w3.org/2009/06/Text-Alternatives-in-HTML5

<Stevef> http://lists.w3.org/Archives/Public/public-html/2009Aug/0781.html

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeExamples

MC: Entering new spec proposal on text alternatives from WAI

<Laura> http://esw.w3.org/topic/PF/XTech/HTML5#head-b71039f2e7034a77a833e320831d9f3a369b7f16

MC: Note tracker issue 31 relation

<Laura> HTML WG ACTION-131: (draft ALT spec).

<Laura> Equivalent Content for Static Images Links: http://esw.w3.org/topic/PF/XTech/HTML5#head-4a8ad6c340c8cf3a2e535f3cf21629d4a43a9612

LH: Can you summarise the practical changes?

MC: Outlines the issue

<oedipus> gregorian versus greggorian

<oedipus> i thought we agreed to this months ago...

LH: Omit alt attibute only in email?

SF: Also the algorithm

<oedipus> can't hear lachy

CS: I think our list is shorter and different

MC: Bug 6494
... Bug 7144
... Both are alt bugs

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/TextAlternativeExamples#head-84fb10a6896277816eb8f081d16b2a9223e8a459

<oedipus> 3 stages of a butterfly's life example with alt and LEGEND, etc.

JS: This could be a proposed discussion in the html accessibility taskforce
... Is there an issue on longdesc

LC: Issue 30 in tracker

<oedipus> i'll go for deprecating LONGDESC if we also ask for deprecation of TABLE for layout

<Laura> http://lists.w3.org/Archives/Public/public-html/2009Oct/0949.html

<oedipus> what is our stance? where articulated

<oedipus> thanks, laura

LC: There was a thread around longdesc

LH: CMN wants longdesc added to the spec

<jcraig> oedipus, can you hear lachy?

<richardschwerdtfe> I don't want longdesc

JS: We are suggesting aria-describedby

<oedipus> The attribute is described already in HTML 4 [1] and the description can be re-used, although it should be made clear that the URI to which longdesc refers can be a relative reference to some part of the same page (in order to be explicit about which content is associated with the image), or a different page. The example, which references an image but appears to provide useless alt text should not be copied from HTML 4. ([1] http://www.w3.org/TR/REC-html40/

SF: Problem there

<oedipus> what about legacy content, which includes W3C TRs

SF: aria-describedby does not do the job, but not saying we need to go back to longdesc

<oedipus> where is the longdesc to HTML5 mapping and can we reference an external as well as internal IDREF

JF: What would pf position be?

<oedipus> putting cart before horse

<oedipus> no to deprecate LONGDESC at the present time

SF: We need to get aria-describedby implemented

<oedipus> amen, kelly

KF: should not lose longdesc

<oedipus> GJR agrees with KF

SF: Some people say that the content that has it is generally useless.

KF: I disagree

<richardschwerdtfe> longdesc should be burried in the back yard. :-)

SF: I did not say I agreed with that position

<oedipus> should have held out 13 years ago for DESCREF

<oedipus> content is useful in CSS2 spec, RWAB XG report, etc.

<oedipus> longdesc content, that is

<oedipus> are you speaking RDFa?

JF: jonas sicking noted that they are going to remove longdesc in a future version of Firefox

<Laura> Chaals' ISSUE-30 (Longdesc) Change Proposal: http://lists.w3.org/Archives/Public/public-html/2009Oct/0949.html

<oedipus> http://www.w3.org/2005/Incubator/app-backplane/XGR-app-backplane-20091030/

<oedipus> RWAB XG final report - section on a11y and 9 longdescs

<oedipus> uses WCAG2 C7 in D links to disambiguate them

<oedipus> JF, what version of FF support LONGDESC natively without plugin?

JS: we have been asked to log things in bugzilla for process

RESOLUTION: Bug 8171 recorded as PFWG on record as regards alt

GJR: should I log my D element and dialogue stuff to the bugzilla or tracker?

JS: We are trying to be on record with issues
... You should look at minutes from this morning as regards process

GJR: OK

<oedipus> what about the future of our relationship to the activity formerlly known as XHTML2?

<Lachy> oedipus, what's your D element and dialogue stuff proposal? Can you post a link?

<oedipus> deprecation of PRE - unecessary with CODE and SAMP or BLOCKCODE

<oedipus> lachy, one second...

<Laura> Have to go now. Bye.

<oedipus> lachy, http://www.w3.org/2002/02/mid/20090917181951.M66606@hicom.net;list=public-html

<oedipus> http://lists.w3.org/Archives/Public/public-html/2009Sep/0725.html

s/video/auio/video/audio

<oedipus> better URI for dialogue issues logged

JS: We can get back to summary later

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/Table/LayoutTABLEDeprecation

<oedipus> very short and simple

SF: What about drag and drop?

JS: I am sure we can go on record with that

<oedipus> PROPOSED: The use of TABLE for layout be DEPRECATED.

<oedipus> RATIONALE: Just as use of BLOCKQUOTE to achieve a stylistic effect was DEPRECATED in favor of stylesheets in HTML 4.01, so, too, should use of TABLE for layout and stylistic purposes should be DEPRECATED in favor of stylesheets.

<oedipus> Proposal Specifics

<oedipus> 1.TABLE should be reserved for tabular data, not for layout purposes; use of TABLE for layout is misuse of a structural element for stylistic purposes

<oedipus> 2.TABLE should be deprecated for "layout" purposes in favor of CSS

<oedipus> 3.for legacy content, a TABLE used for layout MUST be assigned, either by an author or user agent, role="layout" or role="presentation" for that TABLE.

<oedipus> Q.E.D.

<Stevef> scribe:Stevef

<oedipus> scribenick: Stevef

<oedipus> thanks sally

<oedipus> please check layout table deprecation

MC: looking at bug 7721 trying to determine whether it has sufficient detail?

<oedipus> can't we point them at ARIA to suggest an accessible drag and dropping model

<oedipus> rich, have to check the dev.w3.org version of the spec - and you can sign up for update tweets via WHATWG web site

Rich: is it clear in regards to how to impliment or author keyboard accessible drag and drop

<oedipus> will be tweeted when any of HTML5 WG pubs updated

<oedipus> we've already done a lot of the heavy work when it comes to select, drag/copy and drop

<oedipus> can't we reuse what we've done via ARIA to inform them on drag and drop?

Rich: needs explicit explanantion of how to implement keyboard access in browsers for drag and drop

<oedipus> can't hear cyns

MC: implement PF tag

<oedipus> in the body of the spec where drag and drop are introduced]

<oedipus> plus 1 to MC's suggestion

Rich to submit a change proposal on drag and drop

MC: will keep the bug open until rich gets his act together on the change proposal
... volunteer rich for a rough deadline to submit change proposal for drag and drop

<oedipus> YES avoid

resolution: bug 7721 PFWG agreed official issue status of drag and drop

<oedipus> http://esw.w3.org/topic/HTML/DroppedAttributeAccesskey

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements

<oedipus> we have a requirements document which has been extant for over a year

MC: implement accesskey element from XHTML 2

<oedipus> http://esw.w3.org/topic/HTML/DroppedAttributeTabindex

Lachlan: command element supersedes accesskey

<oedipus> rich's requirements for access key replacement: http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements#head-f89f1a568780ea2fbe40a5995b02e3d36073cb47

<richardschwerdtfe> http://dev.w3.org/html5/spec/Overview.html#the-accesskey-attribute

<oedipus> http://esw.w3.org/topic/PF/XTech/HTML5/AccesskeyRequirements#head-f89f1a568780ea2fbe40a5995b02e3d36073cb47

<richardschwerdtfe> Optionally, the user agent may assign a key combination of its choosing as the element's assigned access key and then abort these steps.

JS: what do we want re access/accesskey?

<oedipus> XHTML Access Module: http://www.w3.org/TR/xhtml-access/ (Last Call draft)

<Lachy> I didn't say the command element superscedes accesskey, I said accesskey can be used on the command element

<oedipus> UAWG and SVG WG made significant contributions to XHTML Access Module

<oedipus> hard to hear anyone other than MC

Rich: would be useful to review current accesskey stuff in spec and fo gap analysis in relation to access module.

<richardschwerdtfe> they won't take a curie :-)

<richardschwerdtfe> hi Judy

CS: gregory do you want to take an action to do a change propsoal, go through stuff on the wiki and write a change proposal

<oedipus> GJR to investigate access, access-label, command element

<oedipus> hoping to do for access module what was done for RDFa in HTML5

<oedipus> in other words, yes to cyns

<oedipus> ACTION: Gregory - review current access key / accesskey type attributes in HTML5 and propose from XHTML Access Module [recorded in http://www.w3.org/2009/11/03-pf-minutes.html#action01]

<trackbot> Created ACTION-537 - - review current access key / accesskey type attributes in HTML5 and propose from XHTML Access Module [on Gregory Rosmaita - due 2009-11-10].

MC: another potential issue, accesskey in xhtml can specify modifiers keys as well, couldn't in html4, html5 does

CS: goal is to bring accesskey in line with accesskey module

<oedipus> will carry through on input from UAWG and SVG WG

<oedipus> as reflected in the LC draft of XHTML Access Module

<oedipus> there is an outstanding XHTML2 WG issue on adding more roles to the default list of roles, in particular role="search"

<oedipus> er, role="form"

MC: not seeing ability to combine author/user and usagent defaults to role based access keys

<oedipus> we have role="search", but need role="form" and that should be native to the Role module

GJR: will write proposal before we file bug in tracker

<oedipus> agenda addition suggestion: what to do with the work being done in XHTML2 WG now that XHTML2 itself has been dropped - extending Role, ARIA's relation to role, etc.

<oedipus> SF, hope you can type and talk because i can't hear you!

kellyford: broader class of issues, HTML can create very mouse centric issues, but we need to guard against it.

<oedipus> fyi: http://blog.amplesdk.com/2009/10/31/set-to-go-open-source/

<oedipus> i'm an opera volunteer, so if you implement it, i WILL test it!

MC: do we need to add PFWG to closed bugs? - agrred no

lachlan: scope not allowed on td at the moemnt, so don't know why its fixed

MC: no value, in fixing dupes on fixed header bugs

<oedipus> don't forget http://esw.w3.org/topic/PF/XTech/HTML5/Table/LayoutTABLEDeprecation

<oedipus> janina, thanks - will rejoin then

JS: want more specificty on language selection

<richardschwerdtfe> wow. I just noticed Tantek is in the team room. There is a name I have not heard in a while

<tantek> hello richardschwerdtfe

<richardschwerdtfe> how are you?

<richardschwerdtfe> are you still at that search company?

break for 1/2 hour until 3:30 pacific time

<oedipus> should i call back after the demo?

<oedipus> can you check it without the mouse ;-)

<oedipus> nice and clear, james

<oedipus> is the demo available online?

<richardschwerdtfe> do you have a link?

<richardschwerdtfe> i see

<richardschwerdtfe> ok

<richardschwerdtfe> So, James can you post your demo to the public canvas discussion?

<oedipus> mount demo on he codetalks wiki?

<oedipus> http://www.w3.org/2005/Incubator/app-backplane/XGR-app-backplane/

CS: issues with use of shadow DOM

JC: long development time for alternative approaches

GJR: backplane put out report into using scripts to support declaritive langauges not supported in brwosers
... get accessibility built in to scripting

<oedipus> good news, rich

CS: aria works well for retrofitting, but not for new development

GJR: we needed ARIA 10 years ago, my understanding is that everything in ARIA needs to be nativ ely supported in HTML5?

MC: ARIA is specifically a bridging technology, we want them all to be replaced, but need to focus on making ARIA do what it needs to do

RICH: developers want to do their own thing so we need both

CS: people do custom controls because cannot display native controls using CSS as desired

MC: we should be supporting the a11y engineering to support declaritive markup that can be styled as desired

JS: closer to builtin in HTML5 than HTML4

<oedipus> amen to MC

JS: thanks for the demo, but lets get onto more bugs

<oedipus> http://www.w3.org/AudioVideo/TT/

<oedipus> http://www.w3.org/TR/2006/CR-ttaf1-dfxp-20061116/

<oedipus> cyns have you tried the markup specification "view"

<oedipus> cyns, can you colect examples so we can work on actual wording?

<oedipus> http://dev.w3.org/html5/markup/

<scribe> scribe: jcraig

<oedipus> http://dev.w3.org/html5/markup/aria/

CS: there should be markup examples in the spec

<oedipus> scribenick+jcraig

JS: not rready for a bug, but we shouldn't drop this issue yet
... guests, any thoughts before we move on?

<Lachy> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/232

LH: i have a demo of the <details> element

*shows details toggle demo*

CS: That's what I thought it would be, but the readability of the spec was hard to parse/understand

<oedipus> NOTE: we are now logging to www.w3.org/2009/11/04-pf-minutes.html due to UTC day change

CS: so toggle() would be built in?

LH: yes, native implementation

<oedipus> scribe: jcraig

<oedipus> scribenick: jcraig

CS: doesn't specify whther there is a focus style, default tabindex, etc.

LH: I agree. If it does not specify that, it should.

GR: now logging to new URI, due to GMT date switch

CS: In each tag section, I'd like to see markup code examples and plain English descriptions of browser interaction
... re: command element, if content model is empty, there can't be tags inside?

LH: yes, there is no content, b/c it's a hidden element
... command is bound to other controls, but remains empty
... e.g., menuitemradio example, command element is the data store for data binding other element's views to a single data source

CS: didn't understand relationships between commands and bound elements, that part of the spec could be more clear
... why are synthetic events more limited that physical events
... this worries me. What are the security reasons? b/c this could get in the way of some AT
... The spec should say why it's not allowed

<richardschwerdtfe> say it isn't so

MC: the readability issues could be that we're just not familiar with the docs

JC: in fairness, our own docs have some readability issues too

<richardschwerdtfe> I need to blow this garage

<richardschwerdtfe> you all have a great evening

<richardschwerdtfe> bye

<richardschwerdtfe> :-)

MC: let's review Ben Caldwell's comments

embed element, figure, img, etc

Ben Caldwell comment review

only img and area have @alt

needed for figure, embed, video, canvas, audio, etc.

MC: as in WCAG, it's been unclear as to what "fallback content" means
... even if the content is rendered, is it perceivable to the user
... spec doesn't even provide the ability to render fallback content in other modalities based on user pref or ability

<oedipus> "cascade" of escriptors (alt, title, etc.)

[details of ben's comments, will be submitted to html wg bugzilla]

<kford> Interesting because in UAAG 2 we are looking at asking user agent to offer this cascade of alternatives.

<oedipus> http://esw.w3.org/topic/PF/XTech/Iframe

GJR: spec explicitly forbids iframe resizing

for low vision users, that means excessive scrolling

s/cascase/cascade/

<oedipus> http://esw.w3.org/topic/PF/XTech/IFrame

GJR: cross-check with Open AJAX group

MC: let's switch to low-hanging fruit

<oedipus> caution: fruit may appear to hang lower than it actually does

KF: tomorrow's schedule, create an accessibility birds of a feather table?

JS: it should be more specific than just "accessibility"

JC: 'canvas accessibility' for example

<oedipus> http://www.w3.org/TR/2008/PR-xhtml-modularization-20080611/DTD/xhtml-iframe-1.mod

<oedipus> http://www.openajax.org/member/wiki/OpenAjax_Hub_1.1_Roadmap#Leveraging_IFRAMEs_for_mashup_security

KF: 'media accessibility' too

<oedipus> http://www.w3.org/html/wg/html5/#the-iframe-element

JF: would continue discussion from Sunday

<oedipus> talk to alessio cartucci about flash accessibility -- or MATT!

marquee

LH: on by default , but overrideable by a pref

CS: could cause seizures

JS: browser vendors attorneys should review whether marquee should be on by default

MC: unlikely that marquee will cause seizures

JS: are UAAG comments in HTML bugzilla?

KF: I'll follow up

and make sure they are added to bugzilla

MC: we've now met the chairs request to submit issues

<scribe> ACTION: cooper to create candidate HTML Bugzilla entries from PF comments for PF consideration [recorded in http://www.w3.org/2009/11/04-pf-minutes.html#action01]

<trackbot> Created ACTION-538 - Create candidate HTML Bugzilla entries from PF comments for PF consideration [on Michael Cooper - due 2009-11-11].

JS: What about PF concerns that we're not yet ready to bring up with the HTML WG? How do we track those?
... I'm hopeful the HTML a11y task force will be officially created this week.

MC: we could track them in the PF Wiki

GJR: or ESW wiki
... I'm willing to track the issues there

JS: guests, what areas of out HTML5 review matrix still need the most review?

MC: *summarizes review state of specific sections*

SF: There is ASCII art of dialogs in the spec somewhere. Just a bug.

JS: assigning the HTML5 forms review to both GJR and CS

MC: Drag and drop still assigned to Ben Caldwell

<scribe> ACTION: Rich to review HTML 5 section 7.10 Drag and Drop [recorded in http://www.w3.org/2009/11/04-pf-minutes.html#action02]

<trackbot> Created ACTION-539 - Review HTML 5 section 7.10 Drag and Drop [on Richard Schwerdtfeger - due 2009-11-11].

(missed the action from this morning)

<kford> kford to look at sections 11.1-3 in html 5 spec and also window object from section 6.

Kelly Ford: I will review 11.1, 11.2, 11.3, and I will find someone from UAAG to review the window and windowProxy stuff in section 6

Frank Olivier and James Craig to review contenteditable, section 7.8

<scribe> ACTION: folivier2 to review HTML 5 section 7.8, contenteditable [recorded in http://www.w3.org/2009/11/04-pf-minutes.html#action03]

<trackbot> Sorry, couldn't find user - folivier2

<scribe> ACTION: Frank Olivier to review HTML 5 section 7.8, contenteditable [recorded in http://www.w3.org/2009/11/04-pf-minutes.html#action04]

<trackbot> Sorry, couldn't find user - Frank

<scribe> ACTION: jcraig to review HTML 5 section 7.8, contenteditable (and remind frank olivier to do so as well) [recorded in http://www.w3.org/2009/11/04-pf-minutes.html#action05]

<trackbot> Created ACTION-540 - Review HTML 5 section 7.8, contenteditable (and remind frank olivier to do so as well) [on James Craig - due 2009-11-11].

KF: please file UAAG bugs as well

<oedipus> bless you

<kford> kford will also look at 6.7 on user prompts.

Protocols and Formats Working Group Teleconference

03 Nov 2009

Attendees

Contents