See also: IRC log
<trackbot> Date: 18 November 2010
<paulc> Cynthia is easier to recognize.
<paulc> paulc is on mute
<paulc> NW weather: http://wsdot.wa.gov/traffic/passes/snoqualmie/
JS: Action update, MC can you help
MC: Action 22 on me, organize testing joint task force
... I tried to do this at the TP, I recommend to postpone by 6 months
<MichaelC> action-22 due 31 May 2011
<trackbot> ACTION-22 Organize joint discussion of testing task force and html a11y task force due date now 31 May 2011
MC: Due 31 May 2011
... Action 72 on GR
... Update the definition of image element, GR is not here
... Do you status?
JS: That is still open too
MC: Action 85 on Everit on change proposal
JS: I am hoping that you are ok it, using the TITLE is not a good source as ALT text, we need to document it in the spec
... It maybe the spec says that, if not we need a change proposal, can you do that
Everit: I would agree generally, many authors may use TITLE when they do not use ALT text, is there disagreement?
RS: We discussed this on the ARIA call, but ALT text is considered fall back content, so ALT is rendered when images are turned off
... TITLE would not be used unless there is no ALT
JS: We don't want to discuss the issue now
RS: Should I post the ARIA accessible name algorithm?
JS: yes
<richardschwerdtfe> Accessible Name calclulation: http://www.w3.org/WAI/PF/aria/roles#namecalculation
MC: So we will come back to that
... Action 86 change a change proposal for issue 133
Everit: What is 133?
<kliehm> issue-133?
<trackbot> ISSUE-133 does not exist
MC: Modal segement of the DOM
... Issue 134 command elements
Everit: I am happy to do those 2, can someone point me to an example of a change proposal
<MichaelC> Change Proposals
MC: on the HTML wiki there is instuctions for writing a change proposal
<paulc> Note the due date for 133 is Dec 10: http://lists.w3.org/Archives/Public/public-html/2010Nov/0162.html
MC: There is a list of change proposals, there is varying quality
JS: I am not sure what I would suggest either
<kliehm> http://www.w3.org/html/wg/tracker/issues/133
PC: December 10th is the deadline, should discuss by 3 December
JS: Hopefully we will talk about in a few minutes
<kliehm> http://www.w3.org/html/wg/tracker/issues/134
PC: 133 is significantly more important that 134
<paulc> See http://dev.w3.org/html5/status/issue-status.html for status of all issues
JS: Thanks PC
PC: These should have a due date relative to what going on in the working group
JS: Since 133 is a bit more important, lets do 133 first
JS: Let's discuss this for Everett to write a change proposal
Everit: I was made aware last week, there there is a show modal dialog API
... It will open a URL in a new browser window and return a value, in a modal state
Evrerit: Is this not sufficient means of identifying a modal dialog
Everit: There are some limitations to that method, so people continue to use the javascript way (old way)
... If people use the javascript way then we need to make that accessible too
CS: People don't use it for two reasons, pop-up bloclers stop it and people do not like the windows chrome, so people stopped using it
Everit: I thought about both of those things, it is far more work to load content into a URL, separate a small least of code in content management systems
... So it more than just creating a little HTML code
... We need to have a way for authors to say this is modal code
Evrit: I will take that as ano, are there any other comments?
MS: Sorry I am late
JS: We are working on 133
... Everit has all the guidance we need, the show is yours
MS: Did we go through sub team reports
JS: No, we have those later
MS: Can we change topic to 134
MS: Can you give us some background
<MikeSmith> http://www.w3.org/html/wg/tracker/issues/134
<MikeSmith> ISSUE-134: Provide tablist and tab states for menu and command elements respectively
<trackbot> Sorry... adding notes to ISSUE-134 failed, please let sysreq know about it
Everit: HTML5 doesn't have a way to create a tabbed interface, tab panel, many JS toolkits allow developers to do this
<MikeSmith> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10831
Everit: HTML5 is suppose to enable developers, it should be considered for inclusion
MS: You raised a bug, the bug is marked as fixed, since the eidtor made a change
... reading the editors comment and he thought is is a CSS issue, presentational issue
... Everit responded that it is semantic
Everit: It is both presentational and sematnic, the important part is identifying the tabs and tab panels, what is currently selected and what is in the containers
MS: Something that is the domain of WAI ARIA?
CS: It is covered by ARIA, but it is hard to build in JS, the panel is the child of the tab
... I guess there are two things, it is hard ito build in script
RS: There are alot of UI libraries that have this widget
CS: A lot of UI libraries have then, but it should be available in browsers
RS: I am not sure how they will work on mobile devices
CS: The semantics will allow for rendering on mobile, different presentation and control
MS: The point today is what is the next step to move forward
... We need to decide how big a priority this is, do we move this to last call or not
... This is a critical feature for HTML5?
Everit: yes, I am strongly oppose leaving it to ARIA, I think HTML5 should not consider ARIA as fall back
MS: So what do other s on the call think?
<gfreed> 617.300 is wgbh.
RS: I think it is a nice to have, it introduces problems with interoperability with desktop and mobile technologies for scripting libraries
... I can understand why HTML5 would not commit to implementatino
MC: We don't have many people from browser teams
PC: That questio is better directed at Frank
MS: I agree with RS that it is important, but it is up to developers
RS: There is no question about the importance, but the implementation may be a problem
CS: I am not sure the spec would be that difficult
JS: How much of a spec impact is this?
RS: The HTML5 is very perspective on what UA should do, it will be a little harder for mobile to do, where is the tab panel placed
MS: Everit what is your take on the impact to the spec and user agent implementers?
Everit: Perhaps using stacking on mobile devices, list of tabs wrapping, some people might choose vertical displays, probably easy, but up to the author
... The parent container can be sized and positioned, the borwsers will have default, the author can override with CSS and states
... the rendering is up to the user agent
RS: If this being asked, do we need some specific CSS selectors?
MS: That is a detial to be worked out, before we moe forward we need a change proposal
... It is going to need to have a call from the chairs for concrete proposals.
JS: Everit has agreed to write a change proposal, it doesn't sound like we are in a great hurry
MS: We are at the point to last call
... If we want to get this in, we should have some urgancy, this will probably come up at last call though, others will note this as a deficiency
... Everit when could your proposal be ready?
Everit: Both by december 3rd
PC: 133 is much more important 134
... Maybe its so obvious, but I did not hear the work accessibility
... Was the bug about accessibility, make it easier for authors
Everit: Without this it is harder for authors
PC: You need to motivate people in the change proposal
... That is a really good rationale since that refutes the point of the editor
... I want to encourage you to spend time motivating the change proposals, than rationale
JS: The understanding that we come to the table with, is not the same we are reviewing the change proposals
MS: Anything else anyone wants to say today?
... What's next
JS: Let's check in with the sub teams, I can do media
MS: Let's do media now
JS: We had a long call yesterday, we looked at SRT and what is supported today of the features requirements
... We had presentations on how to use TTL, it is a recommendation today, we had some slides on SRT
... We say 3 major areas of discrepency, it is fixable
... There is one issue in TTML related to live captioning
... The group is frowning on the use of XML, but we are a W3C group
<MikeSmith> Minutes from Media Subteam Mega-Telecon on Wednesday 17
JS: We see that flat navigation is supported, it is not hierarchical, can't do the ePub nesting
... We discussed how it could be done
... Other issues are META data, I can't remember the 3rd issue
... We are not have an opinion of having a strong opinion, but we will emphasize the gaps on what need to be supported
MS: Tank you, good summary
... TOPIC: Bug Triage
<MikeSmith> Minutes of the November 16 HTML Accessibility Bug-Triage teleconference
Martin: Three things...
JS: There is a open mike..
Martin: Looking at the issue of embedded content...
... MC is creating a table we will discuss next tuesday
... We are evaluating new incoming bugs, we are identfying A11y that are important, we need to assure the author and follow up with them
... A11y keyboard issues ...
PC: So the bug triage team complete by January?
MS: We need to look at the rate at which bugs are being resolved
... Martin or MC do you have a response?
Martin: There is not like there is not something happening with the 77 bugs,
PC: The working group has until January to move bugs to issues
MS: MC?
MC: I think we are doing a pretty good job of what is task force priority,
... We try to do what is needed on the bug group, we assign to a likely person, I am not sure when a bug is assigned that is not a responsibility of the triage group , some bugs need the TF disucssiuon, like 133
MS: So one thing we can do to get some data, to take a call next week to do a checkpoint, to make sure we get this done by next week, JS and MC and I can talk about
CS: Tis call is on Thanksgiving next week
MS: Thats right, not call next week
<MikeSmith> minutes: Canvas Subteam of HTML5 Accessibility TF 2010-11-15
RS: We have gone through the modifications to the CANVAS 2D api, that is under way
... The second issue, is like supporting rich text eidting and I issued a number to bugs to the HTML5 spec, that is almost done
... What I am doing now is writing some code, using the canvas sub tree
... We want to make sure we have an API that will drive magification, and something separate for rich text editing, we will need addiitonal APIs, like get spell check errors
... even if we have a canvas sub tree, we do not want to allow FRAMES and IFRAMES, so that is where we are at
MS: How can you avoid that
RS: This is hidden content, we made a lot of progress this week
MS: ANything else?
... No call next week, we will be back on 2 December