- From: Michael Cooper <cooper@w3.org>
- Date: Fri, 20 Feb 2015 13:49:40 -0500
- To: chaals@yandex-team.ru, "public-svg-a11y@w3.org" <public-svg-a11y@w3.org>
- Message-ID: <54E781C4.8020606@w3.org>
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
Received on Friday, 20 February 2015 18:49:47 UTC