Agenda for SVG a11y task force February 20 updated

Hi All,

I added Michael Coopers Abstract for the SVG Accessibility API Mappings to
the agenda. And put the abstract below the agenda.  Rich's wording for
title and desc in the SVG 2 spec follow the abstract in this email.

Time of meeting is 9:00AM EST, 14:00 UTC, duration is 1 hour
Zakim Bridge +1.617.761.6200, conference 2742 ("ARIA"), IRC channel is
#svg-a11y

minutes from Feb 13 meeting:
http://www.w3.org/2015/02/13-svg-a11y-minutes.html

We are using the wiki   https://www.w3.org/wiki/SVG_Accessibility to
capture use cases and ideas.


Agenda

1. Abstract for SVG Accessibility Mappings from Michael Cooper (would be
nice to have published before CSUN) (5 minutes)
2. Rich has text for title and desc in the SVG 2 spec.  The current text
and Rich's proposal are in his email and at the bottom of this email.
3. CSUN - Tuesday evening  (5 minutes)
4. Actions
5. Scope task force from info on wiki
https://www.w3.org/wiki/SVG_Accessibility


----------------------------------------------------- Michael Coopers
abstract for SVG Accessibility Mapping ----------------------------------


Abstract


SVG Accessibility API Mappings (SVG-AAM) defines how (See attached file:
svg-aam.html) map Scalable Vector Graphics (SVG) [(See attached file:
svg-aam.html)] 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) [(See attached file: svg-aam.html)] and the Accessible Name and
Description: Computation and API Mappings 1.1 (ACCNAME-AAM) [(See attached
file: svg-aam.html)] 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 [(See attached file:
svg-aam.html)]. 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 SVG-AAM is part of the WAI-ARIA suite described in the WAI-ARIA
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.


Feedback on any aspect of the specification is accepted. For this
publication, the SVG Accessibility Task Force particularly seeks feedback
on the following questions:
      Are mappings of SVG features clear and appropriate?
      Are ambiguities between the role of WAI-ARIA and SVG features
      resolved?
      Is the relationship of this specification to Core Accessibility API
      Mappings 1.1 and Accessible Name and Description: Computation and API
      Mappings 1.1 clear?
      Is the relationship of this specification to SVG2 and WAI-ARIA 1.1
      clear?


To comment, send email to public-svg-a11y@w3.org (comment archive) or file
an issue in W3C Bugzilla. Comments are requested by 27 March 2015.
In-progress updates to the document may be viewed in the publicly visible
editors' draft.


Publication as a First Public Working Draft does not imply endorsement by
the W3C Membership. This is a draft document and may be updated, replaced
or obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.


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.


This document is governed by the 1 August 2014 W3C Process Document.



------------------------------------------------------ End of Abstract
----------------------------------------------

------------------------------------------------ SVG 2 title and desc
wording -----------------------------------

Current text and logged issues:

Each container element or graphics element in an SVG drawing can supply one
or more ‘desc’ and/or one or more ‘title’ description strings where the
description is text-only. When the current SVG document fragment is
rendered as SVG on visual media, ‘desc’ and ‘title’ elements are not
rendered as part of the graphics. User agents may, however, for example,
display the ‘title’ element as a tooltip, as the pointing device moves over
particular elements. Alternate presentations are possible, both visual and
aural, which display the ‘desc’ and ‘title’ elements but do not display ‘
path’ elements or other graphics elements. This is readily achieved by
using a different (perhaps user) style sheet. For deep hierarchies, and for
following ‘use’ element references, it is sometimes desirable to allow the
user to control how deep they drill down into descriptive text.


Authors should always provide a ‘title’ child element to the outermost svg
element within a stand-alone SVG document. The ‘title’ child element to an
‘svg’ element serves the purposes of identifying the content of the given
SVG document fragment. Since users often consult documents out of context,
authors should provide context-rich titles. Thus, instead of a title such
as "Introduction", which doesn't provide much contextual background,
authors should supply a title such as "Introduction to Medieval
Bee-Keeping" instead. For reasons of accessibility, user agents should
always make the content of the ‘title’ child element to the outermost svg
element available to users. The mechanism for doing so depends on the user
agent (e.g., as a caption, spoken).


Issue: We have this sentence here about tooltips which is stronger than the
earlier note that some implementations do this. We should look at how HTML
describes the ‘title’ attribute and whether a tooltip is required,
suggested, etc., and follow that.


Issue: Once we have said how ARIA attributes can be used in SVG, we might
want to define ‘title’ and ‘desc’ in a manner consistent with them, so that
it is clear what it means for example for an element to have both a ‘desc’
element child and an ‘aria-describedby’ attribute.


Proposed text:

Each container element or graphics element in an SVG drawing can supply one
or more ‘desc’ and/or one or more ‘title’ description strings where the
description is text-only. When the current SVG document fragment is
rendered as SVG on visual media, ‘desc’ and ‘title’ elements are not
rendered as part of the graphics. The 'title' child element represents
advisory information for the element, such as would be appropriate for a
tooltip. On a link, this could be the title or a description of the target
resource; on an image or drawing object, it could be the image credit or
short description of the image; it could be further information about the
source; on interactive content, it could be a label for, or instructions
for, use of the element; and so forth. The value is text. The 'desc'
element represents more detailed, textual information, for the element.
This is typically exposed to assistive technologies to provide more
detailed information, such as help information about the element. The value
is text.

Authors are provided two vehicles for providing a visible label with a
drawing element. The first way is to embed text within the drawing element.
The second is to associate visible text with a drawing element through the
use of aria-labelledby on the element being labelled. Authors may provide a
non-visible label to a drawing element by applying an aria-label to it but
also by providing a descendant <title> element. An author may also expose a
hidden label on an element to an assistive technologies through the use of
aria-labelledby when it points to content that is hidden and contains text.
It is common for user agents to render the <title> element as a tooltip.
Tooltips are an important way to convey alternative text information for a
drawing object where the text label is either not readily visible or could
be rendered in a clearer way in response to passing over the drawing
element with a pointing device. One benefit of using a descendant 'title'
element can be seen when using SVG to to produce an image button or small
drawing that has no visible text but it is important to be able to render a
short textual equivalent label, or tooltip, when a pointing device passes
over the button.

Authors should provide a ‘title’ child element to the outermost svg element
within a stand-alone SVG document. Since users often consult documents out
of context, authors should provide context-rich titles. Thus, instead of a
title such as "Introduction", which doesn't provide much contextual
background, authors should supply a title such as "Introduction to Medieval
Bee-Keeping" instead. For reasons of accessibility, user agents should
always make the content of the ‘title’ child element to the outermost svg
element available to users. The mechanism for doing so depends on the user
agent (e.g., as a caption, spoken).

If the SVG document is embedded in an HTML document, the outermost svg
element may only serve to act as a container for SVG drawings and applying
a 'title' child element may not be of value.  Applying a 'title" element to
the outermost SVG element in this may may result in a tooltip being
generated.

Unlike the desc element, authors also have the ability to associate more
detailed information with content that includes visible text. This can be
achieved by applying aria-describedby to the element, or container of
elements being described and passing an ID reference to content that
includes text that describes the element in question. However, if the text
describing the object is hidden the text within the description would be
exposed to assistive technologies as detailed text information, similar to
a descendant 'desc' element.

Both visual and aural Alternative renderings of ‘title’ element or 'desc'
element are possible through the use of style sheets.

                                                              
                                                              
                    Regards,                     Fred         
                                                              
                   Fred Esch                                  
       Accessibility, Watson Innovations                      
    AARB Complex Visualization Working Group                  
                     Chair                                    
        W3C SVG Accessibility Task Force                      
                   IBM Watson