<trackbot> Date: 24 June 2010

<janina> Meeting: HTML-A11Y telecon

<janina> agenda: this

JS: Action review

MC: Action 20

<MichaelC> close action-20

<trackbot> ACTION-20 Work with Charles to dig up history on column element closed

MC: I pinged WC she dug up good stuff and the action will be closed soon

JS: Is she on time with july dilivery

MC: She has a new job at Microsoft
... Hopefully will be on time
... A number of other actions with extended time lines

JS: Sub team reports
... Technically we do not have a canvas sub team, since the proposal was send to the HTML5
... CMN has now a counter proposal, some people think is compatible with current proposal, additions could be considered counter proposals
... Some people are making progress pulling the two together
... It might lead to an improved proposal, this is my guess at least
... Lets be clear it is not in the hands of the task force, even though discussion is using the same teleconference slot
... Things don't usually get attention until the end

I am mutted

JS: Media sub team has survey out
... The biggest issue is the user requirements, so people can grok what we are saying
... Media accessibility is not necessarily the expertise of many of the current members
... Media accessibility has a long history starting in television and radio broadcasting
... We are trying to clean up the document to more clearly state the requirements
... We are hoping the clarification will setup a path to HTML5 media accessibility
... Looking at federal requirements to develop must or shoulds in the document
... The big issues are technologies for meeting accessibility SRT, SMIL .....
... Any questions on that so far

<chaals> [my canvas proposal: It is nominally compatible but is proposed as an alternative so that we don't ask people to choose which one of two things they should do]

JS: We ran a time survey to find a better time to meet
... Laura cannot meet at this time, the Europe/USA time differences making finding a time difficult
... The survey seems to be inconlusive

<janina> http://www.w3.org/2002/09/wbs/44061/20100617_meeting-time/results

JS: I don; think we can make a decision here, since we do not have many people atending
... Right now it does not seem to make sense to move the time, We will continue to disucss

MS: Hi
... I agree the survey is not definitive
... There might not be enough benefit to change

JS: We want to have a better reason to change
... Our current attempts have not proved to find a better time, any other comments?

none

<Stevef> http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5

JS: SF you have a proposal

<Stevef> http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

SF: The proposal is to text in regards to change the text of the ARIA integration into the HTML5 spec
... The current text is openly restrictive and punitive on the use of ARIA
... Id did not provide guidance to conformance checkers
... We basically rewrote the whole thing, we are still addding the rationale and the descriptions, we are still working on the proposal
... We will be showing the proposal to the sub team

RS: We talked on Monday about itemizing each individual change...

JS: I think you are referring to M??? email , he may have a misunderstanding of the scope of work, he may be thinking it is a response to 85 and 109 it would seem to be too much
... We will talk about this int he HTML5 call later today to clear up any misunderstandings?

RS: Should we be on the call?

JS: It is always good to have you on the call

MS: I think the chairs can handle it
... I'll let you decide who needs to be there

RS: If I am needed I would like to be there, but if not I get the hour back

JS: I think the confusion may be related to 85 and 109, but the proposal covers much more than 85 and 109

SF: I cannot come to the call
... We don't have a specific bug, the bugs need to be specific, is that the climate that we have the specitivity?

MS: I am not completely familiar with the dialog, there should be bugzilla entry for the issue, you should probably file additional bugs if the proposal, change proposals need to speak to bugs

JS: It only enhancing the problem
... Is it 3.2.6?

SF: yes

JS: It might result in dozens of bugs being reported

SF: We are talking about 100s of bugs

JS: The problem is we have is the original section was originally drafted with out the benefit of review form this group
... What is the good approach here?

MS: I think we should table this as a problem and ask the working group for direction from the working group, so it is clear you uncovered a nest of snakes
... the group can then decide what to what to do next and how it fits in the decision process
... Just describe the scenario and ask what we should do

RS: One of the problems you have is that Ian is not an accessibility expert, so we are basically making some corrections

JS: Ian knows HTML5, but does not have the accessibility knowledge, we are doing our best to be HTML5 capable
... we need to get the accessibility domain knowledge into the document
... The sub team has only been together since April, but we have been working on it for months before that
... This proposal we are not expecting to change, but just some API mapping, a week or two away

SF: This wokr has been on going, we working on this last year
... we did this at the FTF last year, the whole process has been in the difference in the charts, there needs to be major changes form the accessibility stand point
... What we have is differences in design philosophy

JS: let me be clear that we do not expect the current proposal to change except by comments of this sub group, the specific API bindings will be completed within 2 weeks
... I don't think anyone wants 100s of bugs filed, if there is a failure on my part to explain the situation that it is more than issue 85 and 109
... I said these are place holders, there is more to it
... Let's not make more of it until we have time to talk about it

SF: The core of it is in the design philosophies and performance
... When we come to moving that forward ...

JS: I would like to hear you and RS talk about how decisions were made, this would be good for the group to hear
... We have legitimate issue, but the taks force seems to be making progress
... RS can you give use a tour of how the thinking went?

RS: SF can do that
... SF is chair

SF: we have the issue of performance issues of ROLE and STATE/PROPERTIES
... A particular role you need a particular state
... ARIA live carte blanche
... The current document has severe restrictions on where ARIA can be used
... In some cases we agree, bt many other s we do not agree
... There already creating widgets and controls out of other elements, that overrides the default roles
... When they change the behaviors ARIA is need to describe that behavior to ATs
... The conflict is when applying a behavior is prohibited in the HTML5 conformance that people should not use this, but there is no way to check to see if authors really use HTML5 as intended
... Event handlers and CSS can be applied to any attributes, unless the element has strong rendering stlye, people can re-purpose for there own behavior, like P, DIV, SPAN
... The philosophy in the current spec is that people will not do this, but there is nothing to stop them from violating this assumption
... ARIA is a way to override the default semantics

RS: The HTML spec does not remove scripting and CSS from those elements, which is not realistic
... For something the spec allows people to do

JS: I would say the spec does not prevent, rather than allow

SF: The net result, is accessibility is built-in at the end or an add on, so we need ARIA to support this use case

JS: We can't change deployed application over night

RS: If we apply ARIA semantics otherwise AT would be confused

SF: We need to override native semantics like checkboxes ...
... It a role is found it will trigger an error
... If they create a button out of a heading and the author thinks it is more important to convey the button behavior, they should be alloed to do it

JS: This provides a device independent way to make web applications accessible
... we need a succinct story on why this is important
... Lets open this to the wider group

RS: Before we go and work on the change proposal, we need to resolve the process

MS: I have sent a message to my co-chairs that we want to bring this up

JS: I sent a mail yesterday discussing this issue, thank you for sending the message
... Anything more about this?

SF: within the task force if we can them to respond to this soon

JS: Yes
... We have this on the table

zakim draft minutes

JS: TPAC FTF meeting we do not have formal slot at this point
... Many of us will be in the same building at the same time, sometimes things get done at FTF

<MichaelC> TPAC meeting page

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 0.99)

Succeeded: s/and Microsoft/at Microsoft/
No ScribeNick specified.  Guessing ScribeNick: jongunderson
Inferring Scribes: jongunderson

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Eric_Carlson IPcaller JS Jon_Gunderson MC MS MichaelC Michael_Cooper Microsoft Mike MikeSmith P24 Paul_Cotton RS Rich SF Steve_Faulkner Stevef aaaa chaals html-a11y janina joined richardschwerdtfe trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Regrets: Denis_Boudreau Laura_Carlson Gregory_Rosmaita Kelly_Ford Ben_Caldwell
Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0210.html
Found Date: 24 Jun 2010
Guessing minutes URL: http://www.w3.org/2010/06/24-html-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report