Re: Fw: SVG WG review of SVG accessibility specifications

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



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 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) and in more detail in the
       second Editor's Note at the end of Section 5.1.1 (Excluding
       Elements).

    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) and also the short note at the end of
       Section 10.3 (Relations).

    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.  Seethe detailed
       note after the use element in the mapping table, and also the note
       at the end of Section 10.1 (Name and Description).

    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.

    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).

    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).  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.)