Re: Proposed Abstract and Status for SVG-AAM

During the approval of the Transition Request I was asked to make an 
edit to the abstract, to move the benefits of the specification ahead of 
the technical details. This is much like what Charles was asking for, 
except I moved it even earlier in the paragraph than I understood 
Charles to be requesting, and was able to make the flow work there. This 
edit is just a moving of existing wording, not a re-wording. The updated 
abstract is:

SVG Accessibility API Mappings (SVG-AAM) defines how user agents map 
Scalable Vector Graphics (SVG) [SVG] markup to platform accessibility 
application programming interfaces (APIs). It is intended for SVG user 
agent developers responsible for SVG accessibility in their user agent.

This specification allows SVG authors to create accessible rich internet 
applications, including charts, graphs, and other drawings. It does this 
by extending the Core Accessibility API Mappings 1.1 (CORE-AAM) 
[CORE-AAM] and the Accessible Name and Description: Computation and API 
Mappings 1.1 (ACCNAME-AAM) [ACCNAME-AAM] specifications for user agents. 
It leverages those core mappings and provides SVG-specific guidance to 
define how the SVG user agent must respond to keyboard focus and role, 
state, and property attributes provided in Web content via WAI-ARIA 
[WAI-ARIA]. The SVG-AAM also adapts the ACCNAME-AAM to make use of 
standard SVG features used to compute accessible names and description 
information exposed by platform accessibility APIs.

The SVG-AAM is part of the WAI-ARIA suite described in the WAI-ARIA 
Overview.

Michael

On 20/02/2015 1:49 PM, Michael Cooper wrote:
> Hi Charles -
> On 20/02/2015 2:13 AM, chaals@yandex-team.ru wrote:
>> A few minor comments:
>> 19.02.2015, 20:51, "Michael Cooper" <cooper@w3.org>:
>>>
>>>
>>>     Abstract
>>>
>>> SVG Accessibility API Mappings (SVG-AAM) defines how user agents 
>>> <cid:part1.05000202.04080400@w3.org> map Scalable Vector Graphics 
>>> (SVG) [SVG <cid:part2.06050807.07070809@w3.org>] markup to platform 
>>> accessibility application programming interfaces (APIs). It is 
>>> intended for SVG user agent developers responsible for SVG 
>>> accessibility in their user agent.
>>>
>>> This specification extends the Core Accessibility API Mappings 1.1 
>>> <http://www.w3.org/TR/core-aam-1.1/> (CORE-AAM) [CORE-AAM 
>>> <cid:part4.01080803.03080605@w3.org>] and the Accessible Name and 
>>> Description: Computation and API Mappings 1.1 
>>> <http://www.w3.org/TR/accname-aam-1.1/> (ACCNAME-AAM) [ACCNAME-AAM 
>>> <cid:part6.01080408.04060805@w3.org>] specifications for user 
>>> agents. It leverages those core mappings and provides SVG-specific 
>>> guidance to define how the SVG user agent must respond to keyboard 
>>> focus and Role; State and Property attributes provided in Web 
>>> content via WAI-ARIA <http://www.w3.org/TR/wai-aria-1.1/> [WAI-ARIA 
>>> <cid:part8.04090503.01090404@w3.org>]. The SVG-AAM also adapts the 
>>> ACCNAME-AAM to make use of standard SVG features used to compute 
>>> accessible names and description information exposed by platform 
>>> accessibility APIs. These features allow SVG authors to create 
>>> accessible rich internet applications, including charts, graphs, and 
>>> other drawings.
>>>
>> The previous sentence should be before the administrative detail, 
>> since it is fundamental information about what is in this specification.
> My view is that the abstract should first explain that it extends both 
> Core-AAM and AccName-AAM, then explain the benefits. While I take your 
> point about putting the fundamental information up front, I think it 
> needs to be after the context setting.
>>>
>>> The SVG-AAM is part of the WAI-ARIA suite described in the WAI-ARIA 
>>> Overview <http://www.w3.org/WAI/intro/aria.php>.
>>>
>> This sentence isn't important to the abstract - especially given the 
>> more detailed description of how it fits in.
> This is a part of the abstract of all the ARIA AAMs, so is there for 
> consistency and completeness. It allows people who wish to follow the 
> link to get a bigger overview.
>>>
>>>
>>>     Status of This Document
>>>
>>> /This section describes the status of this document at the time of 
>>> its publication. Other documents may supersede this document. A list 
>>> of current W3C publications and the latest revision of this 
>>> technical report can be found in the W3C technical reports index 
>>> <http://www.w3.org/TR/> at http://www.w3.org/TR/./
>>>
>>> This is a First Public Working Draft of SVG Accessibility API 
>>> Mappings 1.0 by the SVG Accessibility Task Force, a joint task force 
>>> of the Protocols & Formats Working Group and the SVG Working Group. 
>>> It provides the first concrete guidance on mapping SVG language 
>>> features to accessibility APIs, and addresses both native SVG 
>>> features and ARIA additions. It extends Core Accessibility API 
>>> Mappings 1.1 and Accessible Name and Description: Computation and 
>>> API Mappings 1.1, and is part of a suite of similar 
>>> technology-specific Accessibility API Mappings specifications.
>>>
>> The fact that this document extends others isn't part of its status - 
>> it is in the abstract and should be in the introduction.
> I agree this is not strictly part of the status, but I find it useful 
> to include a high-level overview of what's new in the status. 
> Extending those other specs is actually the main part of what's new 
> for this FPWD. So I think it is useful to keep it here for this 
> version; it wouldn't be in future versions. I agree it also belongs in 
> the abstract and introduction.
>>>
>>> [...]
>>>
>>> This document was produced by a group operating under the 5 February 
>>> 2004 W3C Patent Policy 
>>> <http://www.w3.org/Consortium/Patent-Policy-20040205/>. W3C 
>>> maintains a public list of any patent disclosures (Protocols and 
>>> Formats Working Group 
>>> <http://www.w3.org/2004/01/pp-impl/32212/status>, SVG Working Group 
>>> <http://www.w3.org/2004/01/pp-impl/19480/status>) made in connection 
>>> with the deliverables of the group; that page also includes 
>>> instructions for disclosing a patent. An individual who has actual 
>>> knowledge of a patent which the individual believes contains 
>>> Essential Claim(s) 
>>> <http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential> 
>>> must disclose the information in accordance with section 6 of the 
>>> W3C Patent Policy 
>>> <http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure>.
>>>
>> It is actually allegedly produced by two groups (although one of them 
>> is not chartered, and should be before producing something that is 
>> meant to bind its participants by the Patent Policy).
> This is an issue for the approval of the Transition Request. PF has 
> been operating under charter extension, so this wording should be 
> accurate. If W3M considers the charter extension to be invalid, then 
> they would not approve the Transition Request. But meanwhile for 
> publication preparation I have to put together the content that is 
> meant to be accurate.
>
> Michael
>>>
>>> This document is governed by the 1 August 2014 W3C Process Document 
>>> <http://www.w3.org/2014/Process-20140801/>.
>>>
>>> ,
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>> chaals@yandex-team.ru - - - Find more at http://yandex.com
>