- From: Gunderson, Jon R <jongund@illinois.edu>
- Date: Thu, 24 Jun 2010 11:06:55 -0500
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Link: http://www.w3.org/2010/06/24-html-a11y-minutes.html HTML Accessibility Task Force Teleconference 24 Jun 2010 Agenda<http://lists.w3.org/Archives/Public/public-html-a11y/2010Jun/0210.html> See also: IRC log<http://www.w3.org/2010/06/24-html-a11y-irc> Attendees Present Regrets Denis_Boudreau, Laura_Carlson, Gregory_Rosmaita, Kelly_Ford, Ben_Caldwell Chair Janina_Sajka Scribe jongunderson Contents * Topics<http://www.w3.org/2010/06/24-html-a11y-minutes.html#agenda> * Summary of Action Items<http://www.w3.org/2010/06/24-html-a11y-minutes.html#ActionSummary> ________________________________ <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<http://www.w3.org/2010/11/TPAC/> Summary of Action Items [End of minutes] ________________________________ Minutes formatted by David Booth's scribe.perl<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> version 1.135 (CVS log<http://dev.w3.org/cvsweb/2002/scribe/>) $Date: 2010/06/24 15:58:14 $ ________________________________ Scribe.perl diagnostic output [Delete this section before finalizing the minutes.] 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/<http://dev.w3.org/cvsweb/%7Echeckout%7E/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 [End of scribe.perl<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm> diagnostic output]
Received on Thursday, 24 June 2010 16:07:24 UTC