See also: IRC log
<trackbot> Date: 03 November 2009
<richardschwerdtfe> Hi Sally
<richardschwerdtfe> Hi Loretta
<richardschwerdtfe> what is the scribing rotation?
<richardschwerdtfe> Hi Laura
<jcraig> Zaim, who is on the phone?
<richardschwerdtfe> I will scribe if you like
<inserted> scribenick: richardschwerdtfe
<scribe> scribe: Rich
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
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
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
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
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
<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
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
- 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
<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
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
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...
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?
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.
<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
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> "email@example.com" <firstname.lastname@example.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?
RESOLUTION: Identified <video> and <audio> as an issue of interest formally to pfwg
<oedipus> accesskey replacement requirement?
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
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?
<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
<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
MC: Entering new spec proposal on text alternatives from WAI
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> 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
<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  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. ( 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> 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
<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> better URI for dialogue issues logged
JS: We can get back to summary later
<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> 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> we have a requirements document which has been extant for over a year
MC: implement accesskey element from XHTML 2
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> 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> So, James can you post your demo to the public canvas discussion?
<oedipus> mount demo on he codetalks wiki?
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> cyns have you tried the markup specification "view"
<oedipus> cyns, can you colect examples so we can work on actual wording?
<scribe> scribe: jcraig
CS: there should be markup examples in the spec
JS: not rready for a bug, but we
shouldn't drop this issue yet
... guests, any thoughts before we move on?
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
... 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
MC: let's review Ben Caldwell's comments
embed element, figure, img, etc
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.
GJR: spec explicitly forbids iframe resizing
for low vision users, that means excessive scrolling
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
KF: 'media accessibility' too
JF: would continue discussion from Sunday
<oedipus> talk to alessio cartucci about flash accessibility -- or MATT!
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
... 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.
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/EFWG/PFWG/ Succeeded: s/Kelly/Judy/ Succeeded: s/add PFWG comments/add the PFWG keyword to comments/ Succeeded: s/we will generate a lot of work/we will get a huge amount of comments, and that will generate a lot of work for us/ Succeeded: s/monitor a11y/monitor issues tagged with a11y but not with pf (or pfwg?) as a way to catch issues we may not be aware of/ Succeeded: s/The group that raises it should/depending on the issue, it may be most appropriate for the group that raises it to/ Succeeded: s/believes/believe/ Succeeded: s/mapping/mapping of ARIA features to HTML 5 features/ Succeeded: s/- form task force/- form task force and find co-facilitator/ Succeeded: s/Janina/Judy/ Succeeded: s/implementations/HTML 5 implementations/ Succeeded: s/Canvas definately/Canvas accessibility definitely, though I won't be available that day./ Succeeded: s/Canvas is the custom view within html./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./ Succeeded: s/API rendering/authors having direct access to the accessibility APIs/ Succeeded: s/Sunday/the accessible media summit on Sunday/ Succeeded: s/spec/spec, rather than a 'deprecation'/ Succeeded: s/Identify/Identified/ Succeeded: i/scribe: Rich/scribenick: richardschwerdtfe WARNING: Bad s/// command: s/video/auio/video/audio Found ScribeNick: richardschwerdtfe Found Scribe: Rich Found Scribe: SCain Inferring ScribeNick: SCain Found Scribe: Stevef Found ScribeNick: Stevef Scribes: Rich, SCain, Stevef ScribeNicks: richardschwerdtfe, SCain, Stevef WARNING: Replacing list of attendees. Old list: Rich Janina_Sajka Sally_Cain Kelly_Ford Michael_Cooper James_Craig Frank_Olivier Matt_May Steve_Faulkner Paul_Cotton Loretta_Guarino_Reid Cynthia_Shelly Judy_Brewer Laura_Carlson Sam_Ruby John_Foliot New list: Janina_Sajka Sally_Cain Kelly_Ford Michael_Cooper James_Craig Frank_Olivier Matt_May Steve_Faulkner Loretta_Guarino_Reid Cynthia_Shelly John_Foliot Rich WARNING: Replacing list of attendees. Old list: Janina_Sajka Sally_Cain Kelly_Ford Michael_Cooper James_Craig Frank_Olivier Matt_May Steve_Faulkner Loretta_Guarino_Reid Cynthia_Shelly John_Foliot Rich New list: Laura_Carlson Default Present: Laura_Carlson Present: Laura_Carlson WARNING: Fewer than 3 people found for Present list! Found Date: 03 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/03-pf-minutes.html People with action items: gregory WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]