- From: Janina Sajka <janina@rednote.net>
- Date: Thu, 12 Jun 2014 14:50:23 -0400
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
Hi, Steve: Let me ask Rich to put a quick discussion of this on the Monday ARIA call. Might you be able to join that on the 16th? 17:00 London time? 1PM Boston? Rich: Can we do that up front Monday? Steve, I get that you aren't objecting, but thanks for stating that up front. I must also apologize for questioning whether you were tracking ARIA minutes. I was thinking you would have questioned this sooner based on the posted minutes, but I didn't realize until I went and checked today that the ARIA minutes of 02 June, when this request was discussed, were not posted to the list by our scribe of that day. So, the first reference to them and this action on list was indeed in this CfC. Janina Steven Faulkner writes: > Hi Janina, > > What I think the PF is asking for is that the following MUST requirement in > the HTML 5.0 CR specification be removed or modified: > > "The default implicit ARIA semantics defined below must be recognised by > > implementations for the purposes of ARIA processing. [ARIAIMPL]" > > > > http://www.w3.org/html/wg/drafts/html/CR/dom.html#wai-aria > > It would be really helpful if the nature of the changes to spec text were > provided. > > Note: I am not objecting to the PF requesting changes, I would just like to > be clear on the changes being asked for. > > -- > > Regards > > SteveF > HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> > > > On 12 June 2014 18:39, Janina Sajka <janina@rednote.net> wrote: > > > Thanks, Rich. > > > > So, I think we're might be getting to the clarity that Steve was asking > > for. But, I can't speak for him, of course. So, Steve, would you accept > > this CfC with the clarification that Rich provides? If so, I think we > > can ammend our request accordingly, though we should confirm the amended > > approach on the Monday ARIA call first. > > > > Will that work? > > > > Janina > > > > Richard Schwerdtfeger writes: > > > > > > Janina, > > > > > > I have thought about this some more and we should say that the default > > > implicit semantics should be treated as informative. We need to keep the > > > rules defined in the spec. for strong native semantics where the author > > is > > > restricted in the on the use of roles, states, and properties on specific > > > elements. This can be tested with the a validator or an accessibility > > test > > > tool as these are normative authoring requirements. We don't want to wait > > > until a later version of HTML to start imposing those requirements. The > > > ARIA specification allows a host language to do this: > > > > > > "Host languages MAY document features that cannot be overridden with > > > WAI-ARIA (these are called "strong native semantics" > > > > > > I apologize for not thinking this through more earlier. > > > > > > Best, > > > Rich > > > > > > > > > Rich Schwerdtfeger > > > > > > > > > > > > From: Janina Sajka <janina@rednote.net> > > > To: W3C WAI Protocols & Formats <public-pfwg@w3.org> > > > Date: 06/11/2014 12:37 PM > > > Subject: 48-Hour Call for Consensus (CfC): Make HTML 5.0 Strong > > > Semantics Informative > > > > > > > > > > > > Colleagues: > > > > > > This is a Call for Consensus (CfC) to formally request that the HTML-WG > > > take one of the following two courses of action with respect to > > > strong native semantics in HTML 5.0: > > > > > > > > http://htmlwg.org/heartbeat/WD-html5-20140617/dom.html#sec-strong-native-semantics > > > > > > > > > 1.) Mark this section as RFC2119 "informative" in the current > > 5.0 > > > version of > > > HTML, with a note that it is expected to become normative in a future > > > version of HTML. > > > > > > 2.) Produce testing results that validate maintaning this > > > section's > > > current RFC2119 normative status. > > > > > > The ARIA Task Force believes it may be possible to take the second > > > course of action without an HTML Accessibility API Mappings > > > specification, but such a specification would make the task much > > > simpler. This document is, of course, not yet available for this > > > purpose. > > > > > > This proposal is made by the WAI_PF ARIA Task Force, as discussed in its > > > regular weekly teleconference on 2 June last, logged at: > > > > > > http://www.w3.org/2014/06/02-aria-minutes.html > > > > > > Please reply on list to this email with any objections or concerns. > > > Silence will be interpreted as ascent, though positive > > > messages of support are most welcome. > > > > > > If there are no objections by Close of Business Boston Time Friday 13 > > > June, this CfC will carry, and will be communicated to the HTML-A11Y TF > > > and the HTML-WG as a formal PF comment and request. > > > > > > Janina > > > > > > -- > > > > > > Janina Sajka, Phone: +1.443.300.2200 > > > > > sip:janina@asterisk.rednote.net > > > Email: janina@rednote.net > > > > > > Linux Foundation Fellow > > > Executive Chair, Accessibility Workgroup: http://a11y.org > > > > > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) > > > Chair, Protocols & Formats > > http://www.w3.org/wai/pf > > > Indie UI > > > http://www.w3.org/WAI/IndieUI/ > > > > > > > > > > > > > > -- > > > > Janina Sajka, Phone: +1.443.300.2200 > > sip:janina@asterisk.rednote.net > > Email: janina@rednote.net > > > > Linux Foundation Fellow > > Executive Chair, Accessibility Workgroup: http://a11y.org > > > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) > > Chair, Protocols & Formats http://www.w3.org/wai/pf > > Indie UI http://www.w3.org/WAI/IndieUI/ > > > > -- Janina Sajka, Phone: +1.443.300.2200 sip:janina@asterisk.rednote.net Email: janina@rednote.net Linux Foundation Fellow Executive Chair, Accessibility Workgroup: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols & Formats http://www.w3.org/wai/pf Indie UI http://www.w3.org/WAI/IndieUI/
Received on Thursday, 12 June 2014 18:51:00 UTC