Re: Checking SVG in EPUBs for accessibility

Hi Charles,

Here are some comments on testing of SVG in dPub.

Hi Charles,

Testing graphics in ePub will be complex. One hurdle you can't get around
is SVG graphics in an HTML img element are presentational and nothing
inside the SVG is put in the DOM or available via the accessibility APIs.
So the only choice you have for an SVG in an HTML img is the alt attribute
or if part of a figure a figcaption.

AUTOMATED:All significant images include a title (title element)
AUTOMATED:All complex images include a description (desc element)
An SVG doesn't always need a title or desc. If you have a section in the
pub that describes the same content as the graphic, then references to the
section could be made in a figcaption element or in the SVG element's an
aria-describedby. A figure with a figcaption may not need a title on the
SVG element and the title could be redundant if similar to the contents of
the figcaption or confusing if significantly different. Also different
graphics types may include a title (ie a chart title, not the SVG title
element) in the graphic and it may be referenced by aria-labeledby.

AUTOMATED:All components within an SVG image include a title and desc
This won't be a very valuable test and would return lots of false failures.
You can't add a title or desc to a semantically unimportant element (an
element you don't want in the accessibility tree) as adding the title or
desc will force the element into the accessibility tree. Note, it is an
author error to mark a SVG element with a role of presentation or none and
add a title, desc, aria attribute or tabindex which forces it into the
accessibility tree.

There are multiple ways to convey information to AT, for example title,
aria-label, aria-labeledby and content can all produce an accessible name
for an element.


Language tests
AUTOMATED:The xml:lang attribute set on all root svg elements
MANUAL: The xml:lang attribute set on all instances of foreign language
text within each SVG image

Lang is only needed if the inherited lang isn't the same lang as the lang
of the graphic. You can have lang attributes on title and desc elements
(This feature is planned for SVG 2 but at risk due to lack of
implementations). A program will be able to detect a lang on a title or
desc elements better than a manual check – as it requires looking at the
source for the SVG.

I don't think there are any rules about lang attributes and path elements
which are visible text, since you can't extract the text out of the
graphic.


MANUAL: All presentational SVG images marked using the ARIA role
attribute [R]

This isn't going to be a good test. In SVG you can have non-presentational
children of elements marked with the role none or role presentation. We do
this because non-semantic container elements are often used to pass common
rendering information to semantically important children. We want the
children to end up in the accessibility tree but not the parent group. So
declaring a top level SVG element presentational won't ensure the SVG
doesn't appear in the accessibility tree.

MANUAL: Component definitions re-used whenever possible to simplify
overall comprehension [R]

There are several issues here. One issue is what support will browsers have
for elements referenced by a use element. Another issue is will reusing a
verbose element, make the graphic too wordy? Would using a less verbose
version after the first occurrence be a better approach? Another
consideration is will individual labels help a user keep track of where
they are in a group. Doug's describler did a good job of telling you of the
index of the bar you were visiting (ie bar 4 of 6).

AUTOMATED?:All embedded text content contained in text elements

I don't see how you can test this. Some authoring tools turn text into path
elements. I have seen text split into crazy groups, sometimes a path will
contain a label and sometimes a path contains parts of multiple labels. In
order to assign path's to labels, I have had to manually change to color of
the path to see where it is and what it is part of.

AUTOMATED:Sufficient contrast maintained between embedded text
andbackground image

This will not be easy to test. Some of the problems – text over images,
images with text, text over semi-transparent backgrounds, text over color
gradients and meshes and text that goes over multiple objects. That is only
for the text you can find, same issues for text that are path elements.

MANUAL: Linked components are visually distinguishable from
unlinkedcomponents [R]

There are few affordances in graphics. This is something we should address
post ARIA 1.1

AUTOMATED?:CSS rules defined for title and desc elements to enable
rendering

AFAIK, desc elements are never rendered. You may have to get SVG to allow
this.

MANUAL: Scripting not required to render or understand SVG images
PARTIALLY AUTOMATED?:ARIA roles, states and properties used to enhancethe
accessibility of scripted content

Currently we only have roles, aria properties and tabindex. The only
interactivity supported in SVG 2 is tab based and clicks on links or
embedded HTML.


                                                              
     Regards,                                                 
                                                              
    Fred Esch                                                 
 Watson, IBM, W3C                                             
  Accessibility                                               
                                                              
 IBM Watson       Watson Release Management and Quality       
                                                              






From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: Charles LaPierre <charlesl@benetech.org>, Fred
            Esch/Arlington/IBM@IBMUS, Richard
            Schwerdtfeger/Austin/IBM@IBMUS
Date: 07/17/2016 08:06 PM
Subject: Re: Checking SVG in EPUBs for accessibility



Hi Doug,

Yes, the SVG-AAM will require title & desc from content duplicated with a
<use> element to make its way into the accessibility tree.

As that spec is currently written, we recommend implementing this as a
labelled-by & described-by relationship between the <use> element and its
source.  Once I re-write the spec to follow the shadow DOM model for <use>
elements, it would be implemented by having a copy of the source element
(with its title & desc) as a child of the <use> for the purpose of
generating the accessibility tree.

That said, at this time I would not recommend that authors rely on that
relationship.  Instead, the <use> element should be explicitly labelled,
even if it is just by explicit aria-labelledby and aria-describedby
attributes pointing to the same element as the xlink:href attribute.
(Note, however, that this only works if the element is in the same
document.)

A more general note: a couple of the other checks in Charles' list relate
to features with poor support in web browsers, such as xlink:title and
<font> (both of which are deprecated in SVG 2).  I really don't know enough
about SVG support in EPUB software to know whether they are useful in that
context.

~ Amelia


On 15 July 2016 at 11:34, Doug Schepers <schepers@w3.org> wrote:
  TODO: make sure that the <title> in a referenced shape is put into a11y
  tree when presented in a <use>

  On 7/14/16 3:00 PM, Charles LaPierre wrote:
   Hi Doug,

   So I am helping DAISY with the baseline certification for EPUB books and
   was going through the Accessibility checklist for EPUB3 and went through
   the SVG section and I thought to my self… You know I know a guy who is
   an expert in this and would just love to help me understand this
   better ;)

   So here is what I am trying to figure out what can be programmatically
   checked vs. what would have to be done manually by a human, or a
   combination of the two where a checker could flag the SVG in question
   for some person to check manually..
   The text in italics are my thoughts if you could offer some insight to
   this I would be much appreciative!


     SVG Content Documents and Images


       Language

   AUTOMATED:The xml:lang attribute set on all root svg elements

   /Ie. //<svg//xml:lang="en">///



   MANUAL: The xml:lang attribute set on all instances of foreign language
   text within each SVG image

   /Until we can detect foreign languages with multiple dictionary support
   within the checker this will have to be a manual process./

   /<text//… xml:lang="fr">Je pense...</text>///




       Titles and Descriptions

   AUTOMATED:All significant images include a title (title element)

   /Look for //<title>//…</title> inside <svg> </svg>///



   AUTOMATED:All complex images include a description (desc element)

   Look for <desc>…</desc> /inside //<svg> </svg>///



   AUTOMATED:All components within an SVG image include a title and desc

   /Should be easy enough to test for any embedded graphic for example///

   /<g id="…">/

   /    <title>…</title>/

   /    <desc>…</desc>/

   /</g>/


   MANUAL: All presentational SVG images marked using the ARIA role
   attribute [R]

   /Each SVG image will need to be checked to see if it is purely
   decorative in which case the //<svg//role="presentation">would be
   added./




       Components

   MANUAL: Component definitions re-used whenever possible to simplify
   overall comprehension [R]

   /This is just an optimization in my opinion and could be used to reduce
   repetition, also the Title and/or desc could be defined in the <defs>
   which will need to be considered when checking for <title> & <desc>’s
   automatically.///




       Text Content

   AUTOMATED?:All embedded text content contained in text elements

   /I would think this should also be automated and just look for <text>
   and <tspan> but not sure what we would be looking for in the invalid
   case. //[DougS ??]/

   AUTOMATED:Sufficient contrast maintained between embedded text and
   background image

   /There should be a way to automate this since contrast checkers already
   exist for Websites///

   AUTOMATED?:Custom fonts used in place of creating text as images

   /I would think this should also be automated and just look for <font>
   but not sure what we would be looking for in the invalid
   case. //[DougS ??]/




       Linking

   AUTOMATED:All embedded links include an xlink:title attribute explaining
   the target location

   MANUAL: Linked components are visually distinguishable from unlinked
   components [R]

   /Not sure what options are available to distinguish linked vs.
   unlinked.  [DougS ??]///




       Styling

   AUTOMATED?:CSS rules defined for title and desc elements to enable
   rendering

   /I believe this could be tested automatically.  We can also ensure no
   /style/attribute directly added to graphical components///

   PARTIALLY AUTOMATED:Visual styling of components separated into CSS
   style sheets to facilitate reader customization [R]

   /We may be able to detect CSS style sheets are used, and flag them for
   review if none are found. //[DougS ??]/




       Interactivity

   MANUAL: Scripting not required to render or understand SVG images

   PARTIALLY AUTOMATED?:ARIA roles, states and properties used to enhance
   the accessibility of scripted content

   /We can detect when ARIA roles are present, the trick will be to know
   when they are missing for an interactive.  There may be a way to handle
   this.///

   AUTOMATED?:Text equivalents are updated whenever dynamic content changes

   /There may be a way to ensure state changes have text equivalent, but
   will need help from //[DougS ??]/

   / /

   ?Not Sure?Device-independent events used for all interactive
   actions/. //[DougS ??]/


   Thanks Doug for any help you can offer, I will owe you one.  Buy you a
   drink at TPAC :)


   Thanks
   EOM

   Charles LaPierre
   Technical Lead, DIAGRAM and Born Accessible
   E-mail: charlesl@benetech.org <mailto:charlesl@benetech.org>
   Twitter: @CLaPierreA11Y
   Skype: charles_lapierre
   Phone: 650-600-3301