Re: Proposed Abstract and Status for SVG-AAM

Sounds good Michael. It will be even better with the new semantics for
charts, etc. That will be coming from the group.

Am I correct in assuming that you don't require a task force consensus vote
to make this change? I am hoping not. :-)

Best,
Rich


Rich Schwerdtfeger



From:	Michael Cooper <cooper@w3.org>
To:	chaals@yandex-team.ru, "public-svg-a11y@w3.org"
            <public-svg-a11y@w3.org>
Date:	02/24/2015 02:02 PM
Subject:	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 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 extends 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. 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.


            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 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. W3C maintains a public
                  list of any patent disclosures (Protocols and Formats
                  Working Group, SVG Working Group) 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) must disclose the
                  information in accordance with section 6 of the W3C
                  Patent Policy.


            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.


                  ,



            --
            Charles McCathie Nevile - web standards - CTO Office, Yandex
            chaals@yandex-team.ru - - - Find more at http://yandex.com