Re: Fw: SVG WG review of SVG accessibility specifications

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Fw: SVG WG review of SVG accessibility specifications

Richard Schwerdtfeger

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" <[hidden email]>
Cc: "Amelia Bellamy-Royds" <[hidden email]>, 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 WatsonWatson Release Management and Quality

----- Forwarded by Fred Esch/Arlington/IBM on 11/12/2015 02:11 PM -----

From: Amelia Bellamy-Royds <[hidden email]>
To: www-svg <[hidden email]>
Cc: SVG-A11y TF <[hidden email]>
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 Modulehttp://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: (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.)

Reply | Threaded
Open this post in threaded view
|

Re: Fw: SVG WG review of SVG accessibility specifications

Doug Schepers-3
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" <[hidden email]>
> Cc: "Amelia Bellamy-Royds" <[hidden email]>, 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 <[hidden email]>
> To: www-svg <[hidden email]>
> Cc: SVG-A11y TF <[hidden email]>
> 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.)
>

Reply | Threaded
Open this post in threaded view
|

Re: Fw: SVG WG review of SVG accessibility specifications

Richard Schwerdtfeger

thank you


Rich Schwerdtfeger


Inactive hide details for Doug Schepers ---11/12/2015 02:05:52 PM---Hi, Rich– I think this should be fine.Doug Schepers ---11/12/2015 02:05:52 PM---Hi, Rich– I think this should be fine.

From: Doug Schepers <[hidden email]>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, Fred Esch/Arlington/IBM@IBMUS
Cc: Amelia Bellamy-Royds <[hidden email]>, SVG WG <[hidden email]>, SVG public list <[hidden email]>
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" <[hidden email]>
> Cc: "Amelia Bellamy-Royds" <[hidden email]>, 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 <[hidden email]>
> To: www-svg <[hidden email]>
> Cc: SVG-A11y TF <[hidden email]>
> 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.)
>