Re: Fw: SVG WG review of SVG accessibility specifications

thank you


Rich Schwerdtfeger



From: Doug Schepers <schepers@w3.org>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, Fred
            Esch/Arlington/IBM@IBMUS
Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, SVG WG
            <public-svg-wg@w3.org>, SVG public list <www-svg@w3.org>
Date: 11/12/2015 02:05 PM
Subject: Re: Fw: SVG WG review of SVG accessibility specifications



Hi, Rich–

I think this should be fine.

Thanks for your diligence.

Regards–
–Doug

On 11/12/15 3:01 PM, Richard Schwerdtfeger wrote:
> Doug,
>
> The reason I have not attended SVG calls as the last reschedule they
> moved the meeting over a conflicting meeting. So, if you could get the
> group to sign off up publications - at least for the SVG-AAM (which is a
> heartbeat publication) tonight that would be very helpful.
>
> The ARIA Graphics module we want to pub. the first week of December as
> it is a FPWD.
>
> We want to lock down the SVG-AAM for tomorrow for publication of a
> heartbeat in the next week.
>
> I will be updating the SVG ARIA section late in the next few weeks to
> reflect changes to ARIA 1.1 and our revised mapping table. We are
> refreshing ARIA 1.1, the ARIA graphics module, and a number of the
> accessibility api mapping specifications in the next 1-2 weeks. I want
> to keep SVG in synch.
>
> Best,
>
> Rich
>
>
> Rich Schwerdtfeger
>
> Inactive hide details for Fred Esch---11/12/2015 01:22:47 PM---Doug, Can
> you get these two doc reviews on the SVG WG agenda - aFred
> Esch---11/12/2015 01:22:47 PM---Doug, Can you get these two doc reviews
> on the SVG WG agenda - and hopefully get the working groups
>
> From: Fred Esch/Arlington/IBM
> To: "Douglas Schepers" <schepers@w3.org>
> Cc: "Amelia Bellamy-Royds" <amelia.bellamy.royds@gmail.com>, Richard
> Schwerdtfeger/Austin/IBM@IBMUS
> Date: 11/12/2015 01:22 PM
> Subject: Fw: SVG WG review of SVG accessibility specifications
>
> ------------------------------------------------------------------------
>
>
> Doug,
>
> Can you get these two doc reviews on the SVG WG agenda - and hopefully
> get the working groups approval for us publishing a heartbeat (SVG AAM)
> and a first working draft (Graphics Module)?
>
>
> Regards,
>
> Fred Esch
> Watson, IBM, W3C Accessibility
> IBM Watson   Watson Release Management and Quality
>
>
> ----- Forwarded by Fred Esch/Arlington/IBM on 11/12/2015 02:11 PM -----
>
> From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
> To: www-svg <www-svg@w3.org>
> Cc: SVG-A11y TF <public-svg-a11y@w3.org>
> Date: 11/11/2015 02:30 AM
> Subject: SVG WG review of SVG accessibility specifications
> ------------------------------------------------------------------------
>
>
>
> A reminder that there are two specifications that the  SVG Accessibility
> Task Force is hoping to publish in the coming weeks.  One is an updated
> working draft, the other a first draft:
>
>   * *The SVG Accessibility API Mapping specification* (aka SVG-AAM),
>     _https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html_.

>     This would define how user agents should interpret SVG content when
>     creating an accessible representation of a document.  It includes,
>     for example, the default ARIA roles for different elements, and how
>     title and desc should be used to generate accessible names and
>     descriptions.  This is a significant update from the working draft
>     published last February, although there are a number of outstanding
>     issues that will not be resolved in this publication round.
>   * *The ARIA Graphics Module*,
>     _http://rawgit.com/w3c/aria/master/aria/graphics.html_.

>     This defines new ARIA roles that would form the foundation of a
>     description of structured graphics, such as diagrams.  The img role
>     from ARIA 1 is not sufficient for complex SVG, because it assumes
>     that an image has a single text description, and no meaningful child
>     content.  The new roles would allow graphical objects to contain
>     other objects with their own descriptions, and possibly with
>     interactive components.  This document would then form the
>     foundation for a future, more complex role model that could describe
>     the semantics of complex charts and maps.  This would be a first
>     pass working draft.
>
> I (and hopefully Doug and maybe Rich) will be available to discuss the
> main issues on the teleconference this week.  However, comments and
> questions by email are of course welcome as well.  After that we'll
> probably ask for a resolution via email responses (or at least, via an
> absence of email objections within a reasonable time frame!).
>
> I've copied below a summary of the outstanding issues for SVG-AAM (which
> I sent to the SVG accessiblity task force list last week).  The task
> force is doing our final review of the ARIA Graphics module this week,
> but I think it's less controversial.
>
> Best,
> Amelia
>
> ___________________________________________
>
> SVG-AAM Status
>
> Remaining things to do before publication:
>
>     1. *valid URL for editor's drafts:* Sort out the process for
>     creating regular snapshots of the Editor's Draft in Github pages
>     (_w3c.github.io_ <http://w3c.github.io/> domain), and update the
>     Editor's Draft URL accordingly (it currently points to rawGit, which
>     provides an up to date reflection of the document, but is not
>     intended for wide use).
>
>     2. *admin tidying*: Update dates and other status of document text.
>
>     3. *name and description edits:* If possible, coordinate with the
>     editors of the Accessible Name spec about refactoring the name &
>     description algorithm to improve readability, and update our text in
>     response.  I'll start working on a proposal this afternoon, but I'm
>     not sure whether this will happen in the next few weeks.  If not, we
>     may wish to add an Editor's note.
>
> In addition, the following outstanding issues are recorded in Editor's
> notes, and won't be addressed for this publication round:
>
>     1. *hidden elements:* Coordinate with the editors of the CORE-AAM
>     spec regarding the definition of 'hidden' elements.  See the _short
>     note at the end of Section 3 (Important Terms)_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote1> and
>     in more detail in_ the second Editor's Note at the end of Section
>     5.1.1 (Excluding Elements)_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote3>.
>
>     2. *complex desc content:* Explore whether there should be other
>     ways to make <desc> content directly browsable in a way that exposes
>     structured child content.  See the_ first note at the end of Section
>     5.1.1 (Excluding Elements)_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote2> and
>     also _the short note at the end of Section 10.3 (Relations)_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote8>.
>
>     3. *use elements:* Determine whether a more complex representation
>     of the re-used content is required.  If so, determine how to
>     represent it and what special computation is required.  If not,
>     consider whether the name and description proposal is sufficient.
>     See_the detailed note after the use element in the mapping table_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote6>,
>     and also _the note at the end of Section 10.1 (Name and
>     Description)_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote7>.
>
>     4. *graphics roles:* Update some of the default mappings to use new
>     ARIA graphics roles, once we have appropriate platform API mappings
>     for those roles.  Also, coordinate with the main ARIA team regarding
>     getting better roles for structured text (e.g., a paragraph role).
>     See various notes and editor's notes within_ the role mapping table_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#mapping_role_table

>.
>
>     5. *SVG views:* Determine whether the proposal for SVG views is
>     sufficient, and coordinate with the SVG WG regarding viewTarget.
>     See _the note at the end of Section 10.5 (SVG Views)_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote9>.
>
>     6. *Animation and ARIA:* Coordinate with the SVG WG regarding
>     whether ARIA attributes are modifiable with declarative animation.
>     See _the note at the end of Section 10.6 (Declarative Animation)_
>     <
http://rawgit.com/AmeliaBR/aria/svg-aam/svg-aam/svg-aam.html#h-ednote10>.
>     I've delayed following up on this because of the controversy over
>     whether animation elements should be deprecated, but that seems to
>     have stabilized, so I should look into it again.
>
> (P.S. Links are to my branch on rawgit, and if you're reading this mail
> in the archives long after it is written, they will likely no longer go
> to the correct points in the document, if they work at all.)
>