Re: Comments on SVG Accessibility Mappings -- Language and Scope

Rich Schwerdtfeger

Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com> wrote on 01/19/2015
07:46:36 PM:

> From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
> To: public-svg-a11y@w3.org
> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Date: 01/19/2015 07:47 PM
> Subject: Comments on SVG Accessibility Mappings -- Language and Scope
>
> I've carefully reviewed Richard's draft spec on default SVG
> accessibility mappings.  Below are general (and often nitpicky)
> comments on the language and scope of content.  I'll send a separate
> email with detailed discussion of the default and allowed semantics.
>
> At this point, I'm mainly focused on outlining concerns; if others
> agree that those concerns are valid, I would of course be happy to
> help come up with alternatives!
>
> Best,
> Amelia BR
>
> __________________________________________________
>
> Comments on
> SVG2 Accessibility API Mappings
> ===============================
> W3C Editor's Draft 16 January 2015
>
> http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html
>
> General
> -------
>
> Should we remove the `2` from the title?  It is possible that this
> report will be finalized before anything titled "SVG2" is ready.
> Furthermore, we want to encourage user agents and authors to start
> using the API as soon as possible, irrespective of implementation
> status of other SVG2 features, and to retroactively apply it to
> SVG1/1.1 content.
>
done. See response to Erik's post.

> To make this document a stand-alone enhancement to SVG 1.1, perhaps
> we could include the normative text from SVG2 that specifically adds
> the ARIA 1 attributes to all SVG elements.  Or would that be
> confusing the purpose of the document?
>
We do that in SVG2. However, there are elements in SVG 1.1 that will not
exist in SVG2 and they will disappear from browsers.
Also, it some elements it makes no sense to apply an ARIA role to. See
section 5.10.3.
https://svgwg.org/svg2-draft/struct.html#implicit-aria-semantics


> More broadly, what *is* the purpose of the document?  Is it only for
> implementers, or is it for authors as well?  Will we be creating a
> separate document with guidance for authors?  (Possibly as a
> graphics-related section of the main WAI-ARIA authoring practices
> note.)  Many of my comments that follow relate to the fact that the
> language may be confusing for authors; if there will be a parallel,
> author-focused document that is less of an issue.
>
This document is for user agent developers. It is to ensure that the
browser maps the content properly to platform accessibility API services
layers.
Authors, I hope, do not have to look at this. We need a separate authoring
practices document.

> Abstract
> --------
>
> - Should have a clearer statement about the target audience (UA
> implementers vs document authors).
>
Done.

> - Should make it clearer that it extends/replaces the accessible
> name computation for SVG elements.
>
Done.


> - More generally, I would prefer to re-arrange to have the first
> sentence or two stand alone with the information about why this is
> important, moving the links to other documents farther down.
>
Done.

> 1.0 Introduction
> ----------------
>
> - Not sure why the statement about showing/hiding GUI components is
> relevant.  ATs need to access components that are always visible in
> a GUI, too.
>
The point is that hidden components are not typically exposed to assistive
technologies unless they are used as part of an alternative text and
description computation. This is extremely important. As you know authors
often hide content until it is needed and exposing it complicates the user
experience.  The hiding of content and how it is dealt with is handled in
the core specification. This is an extension of the Core specification
targeted at SVG user agents. This is also the case for HTML.


> - There should be a paragraph about the fact that SVG 1 and 1.1
> included elements for accessibility purposes (e.g. `<title>` and
> `<desc>`), but that to date there has been no formal guidance on how
> UAs should present this information to ATs, or how to integrate with
> other languages and validators that use the ARIA system.
>
done.



> - I don't like the "Unlike earlier versions of SVG" statement re DOM
> and events.  It suggests that earlier versions of SVG didn't have a
> clear DOM, when what you really mean is that SVG 2 updates the SVG
> DOM to DOM 3.
>

this was addressed per changes based on Erik's comments.


> - The reference to ARIA 1.1 as "a planned W3C recommendation" should
> make it clear that it is an update of an existing recommendation (ARIA
1).
>
If 1.0 were not a recommendation we would not have a 1.1. I am not
following the logic but I have tweaked it.



> 1.1 Accessibility APIs
> ----------------------
>
> - I think the distinction between "static" web pages and rich
> internet applications is not as useful as the distinction between
> semantic markup and custom web applications.  The paragraph that
> starts "In the case of static Web pages" later discusses "UI
> elements that are known to be interactive", but that's somewhat
> buried for a reader skimming through.
>

Yes, I have been meaning to update that section as it is a bit dated. I
have now updated it.




> 1.2 The Accessibility Tree and the DOM Tree
> -------------------------------------------
>
> no comments
>
> 2.0 Normative User Agent Implementation Requirements for SVG 2
> --------------------------------------------------------------
>
> This is all standard boilerplate; only comment is re the section
> title, and whether we want to restrict this document to SVG 2 or
> just say "for SVG".
>
Done. SVG.

> 3.0 Important terms
> -------------------
>
> Accessibility Subtree::
> Is an aria-owns relationship part of a subtree?
>
This implementation of this is platform dependent. You should look at the
Core Mapping spec. for details.

> Hidden::
> Should make it clear that an element can be hidden implicitly via
> CSS or language semantics, not just by explicitly setting `aria-hidden`.
>

The terms glossary is included in other mapping specs. I have created an
issue but it will not be addressed before going to
First Public Working Draft as it effects other specs:
https://www.w3.org/WAI/PF/Group/track/issues/696

> Live region::
> This sentence does not make sense: "Since these asynchronous areas
> are expected to update outside the user's area of focus, assistive
> technologies such as screen readers have either been unaware of
> their existence or unable to process them for the user."  Maybe
> replace "are expected to" with "frequently"?  Or else keep "expected
> to" and change the second clause to a forward-focused "ATs need to
> be made aware of the changes and how to process them...".
>
We don't know that these areas update frequently. I don't see an issue with
the text. AJAX live regions update out of focus and ARIA liver regions
indicate to the AT where they exist and how to handle them.




> Owned element/Owning element::
> Should these definitions reference the accessibility tree/subtree
> definitions (or vice versa)?
>
No because these terms are also used by authors in the ARIA spec. Not
everyone needs to be exposed to the low level accessibility API mappings.




> Role::
> Should clarify that roles apply to objects in the accessibility tree
> / elements in the markup.
>

Same comment as above.


> Root WAI-ARIA node::
> Do we really want to reference `<frameset>` as an example?
>
This is left over from when we started ARIA where we were dealing with
HTML4. I agree we can remove frameset. I have created an issue on this as
it effects other specs.

https://www.w3.org/WAI/PF/Group/track/issues/697

This should not be a show stopper for first public working draft.


> Target element::
> Clean-up code formatting.
>
Done.

> Valid IDREF::
> I would change to "A reference to a target element in the same
> document whose ID matches the IDREF value."  The current wording
> could be read as implying that two elements should have matching IDs.
>
Done.


> 4. Supporting Keyboard Navigation
> ---------------------------------
>
> If this document will be generalized to apply to all SVG, not just
> SVG2, then there should be some content added here about keyboard
> navigation and SVG 1.1
>
Done.


> 5. Mapping WAI-ARIA to Accessibility APIs
> -----------------------------------------
>
> For 5.1, do you really mean "this section must conform" (as in,
> please ignore any content of this document that conflicts with the
> linked reference), or do you mean "SVG user agents must conform",
> similar to the following sections?
>
yes. It gets a bit ugly to not reference the appropriate part of the ARIA
specification where these sections must conform.

> For 5.2, is there a benefit in referencing the SVG2 spec as the
> "host language"?  Wouldn't it make more sense to reference section
> 5.4.2 of this document, which defines the native markup semantics by
> mapping to roles?
>

We don't reference the SVG2 spec. as THE host language per Friday's call.
One issue we are going to have to deal with as a group is what do we do
with SVG elements that will disappear from SVG1.1 to SVG2. I think that is
TBD as to my knowledge I see no indication that Microsoft will support
animation in SVG other than through CSS.


> 5.4 Role mapping
> ----------------
>
> I don't find the long list/table the most effective way to present
> this information.  I think it would be clearer if the default
> semantics were defined by grouping all SVG elements into categories,
> and then defining the default and allowed roles for each category.
> An alphabetical list of elements could then be used to look up which
> category each element is in.
>
Yes. working on that. I am looking at your other post.

> This would avoid repeating the same text about checking for
> accessible name content again and again, and should make it easier
> to catch errors (like ellipse not having the same instructions as
> other shapes, in the current draft).
>
> See separate email for suggested categories and comments on the
> mappings themselves.
>
>  5.6 Special Processing Requiring Additional Computation
>  -------------------------------------------------------
>  This section really needs to be expanded to be informative for
> authors.  Both authors and implementors should be able to look at a
> single document and understand how `<title>` and `<desc>` interact
> with the corresponding ARIA attributes; which take precedence, does
> one replace the other or are they combined, and so on.
>
This spec. is NOT for authors.

>  I think we should also explicitly encourage authors to use
> `<title>` and `<desc>` (host language semantics), with the caveat
> that `aria-label` or `aria-labelledby` should be used instead of
> `<title>` if the tooltip value doesn't make a good accessible name
> or vice versa.

That belongs in an authoring practices. guide.