- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 19 May 2015 07:43:00 -0500
- To: "SVG WG" <public-svg-wg@w3.org>, "Cameron McCormack" <cam@mcc.id.au>
- Cc: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, public-svg-a11y@w3.org
- Message-ID: <OF6AFED1AA.DFC786FF-ON86257E4A.0045709B-86257E4A.0045DAEC@us.ibm.com>
I am working on the SVG accessibility mapping guide and ran across what we
believe to be an error in the spec.
I agree with Amelia on this. Cameron, others do you mind if I modify the
spec. to remove descriptive elements from the <switch> content model?
Rich
Rich Schwerdtfeger
----- Forwarded by Richard Schwerdtfeger/Austin/IBM on 05/19/2015 07:38 AM
-----
From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: public-svg-a11y@w3.org
Date: 05/18/2015 05:06 PM
Subject: Re: Action-1634: the switch element and <title> and <desc>
Yes, the spec is wrong. Or at least inconsistent. It allows you to do
something that looks like it would be useful but is actually useless.
You can put a title and desc inside a switch, just like you can put them
inside any other container element. However, you can't put a switch inside
a shape to switch between titles for that shape. You can put a switch
inside a group, and titles inside that switch, but those titles won't be
associated with the parent group, they'll be associated with the switch.
So a switch will never be used to select the title or desc for an element.
And, since titles and descriptions aren't explicitly excluded from the
switch's switching rules, you can't use them to describe the switch as a
container element itself. If you include a title as the first child of a
switch, that will be the child element that gets selected for the switch,
and all the other content within the switch construct will be ignored. If
something else is included first, the title/desc will be ignored. So a
switch will never have a meaningful title or desc itself; if it does, it
has no content to be named!
In other words, I should probably recommend that SVG 2 remove "descriptive
elements" from the content model for <switch>.
Amelia
On 18 May 2015 at 15:13, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
Amelia,
Perhaps I am reading this wrong but the <switch> element states that it
can be a container for a range of different elements including
"descriptive elements"
When I follow the link for descriptive element i get:
http://www.w3.org/TR/SVG2/struct.html#TermDescriptiveElement
That text states the following:
An element which provides supplementary descriptive information about its
parent. Specifically, the following elements are descriptive elements: ‘
desc’, ‘metadata’ and‘title’.
Is the spec. wrong?
Rich
Rich Schwerdtfeger
Inactive hide details for Amelia Bellamy-Royds ---05/16/2015 07:34:18
PM---Hi Richard, You're confusing two issues: language swAmelia
Bellamy-Royds ---05/16/2015 07:34:18 PM---Hi Richard, You're confusing
two issues: language switching for <title> and <desc>
From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, public-svg-a11y@w3.org
Date: 05/16/2015 07:34 PM
Subject: Re: Action-1634: the switch element and <title> and <desc>
Hi Richard,
You're confusing two issues: language switching for <title> and <desc>
versus content switching with <switch>. The multi-language alt text
options *won't* use <switch> because it wouldn't be backwards
compatible. My response is therefore two parts...
____________________
For the accessible text selection:
The current text mostly looks good, except that the final sentence seems
to be mangled.
Here is a light edit:
Otherwise, unless the element is marked as presentational
(role="presentation" or role="none"):
If performing a text alternative computation for an
accessible name and the current node provides a descendant
<title> element chosen based on the language rules for
the SVG specification, return the <title> element's text
content as a flat string.
If performing a text alternative computation for an
accessible description, and the current node provides a
descendant <desc> chosen based on the language rules for
the SVG specification, return the concatenated text and child
content of that <desc> element.
I've moved the "unless the element" bit to the top to make it clear that
we're talking about the element being named, not the title/desc element.
There should be no role on title/desc, and its obligatory role is none,
but that doesn't prevent it from being used as the name for its parent.
I've used "the concatenated text and child content of that <desc>
element" because the SVG 1.1 specifications allow complex content within
<desc>, including content from other namespaces. This has been used in
practice to include HTML markup within the description, although the
specs don't specifically say what to do with it. Feel free to replace
with a better wording. It really should be the same wording as for
aria-describedby; there is an editorial note in ACC-Name saying that they
need to come up with explicit wording for aria-describedby, so we would
want to pass our wording by them!
__________________
For <switch>:
A <switch> changes which elements are rendered to the screen, so it
should be addressed when building the accessibility tree. A switch
should never have any title/desc of its own. The SVG 1 specs didn't
specifically say that I can't have them, but they also don't exclude
title/desc children from the switching mechanism, so including them never
has the intended consequence!
I would therefore lean towards making <switch> an obligatory
role="none" / no role may be applied. It's not quite presentational in
the sense that using tables for layout is presentational, but it's only
impact is on which other elements get displayed. Does anyone think that
is too strict? It would mean ignoring any aria-label or other
attributes. Authors might add these if they are treating the <switch> as
a group containing multiple presentations of the same content.
As far as dealing with the switch behavior, that should go in section
5.1, which currently just references CORE-AAM (
http://www.w3.org/TR/core-aam-1.1/#mapping_general). In that spec, there
are rules for excluding or including elements in the accessibility tree.
I think we need a paragraph (possibly more informative than normative)
about how those rules should apply to SVG: how they apply to non-rendered
graphical elements, as well as how they apply to switch-ed content.
I'll read over the CORE-AAM section and put together a draft text for the
SVG doc.
__________________
There are two other SVG elements that I think need special treatment:
<view> and <use>. I'll send separate notes on them.
Best,
Amelia
On 14 May 2015 at 09:51, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
https://www.w3.org/WAI/PF/Group/track/actions/1634
I am proposing a modification to the text of the accessible name
and description computation to better address the <switch> element.
Please review:
Here is the current text for step F of the SVG name and description
computation (
http://www.w3.org/TR/svg-aam-1.0/#mapping_additional_nd):
Otherwise, if performing a text alternative computation for an
accessible name and the current node provides a descendant <title>
element chosen based on the language rules for the SVG
specification, return the title text alternative as a flat string,
unless the element is marked as presentational (role="presentation"
or role="none"). If performing a text alternative computation for
an accessible description, and the current node provides a
descendant <desc> chosen based on the language rules for the SVG
specification; return the description text alternative an
accessible description computation attribute as presentational
(role="presentation" or role="none").
Proposed Text:
Otherwise, if performing a text alternative computation for an
accessible name and the current node provides a descendant <switch>
element with one or more descendant <title>s return the title text
alternative as a flat text string determined by the switch, unless
the element is marked (role="presentation" or role="none");
otherwise if the current node does not provide a descendant switch
element, but it does provide a descendant <text>, return the title
text of the first descendant <title> element as a flat text string,
unless the element is marked (role="presentation" or role="none").
If performing a text alternative computation for an accessible
description and the current node provides a descendant <switch>
element with one or more descendant <desc>s return the description
text alternative as a flat text string determined by the switch,
unless the element is marked (role="presentation" or role="none");
otherwise if the current node does not provide a descendant switch
element, but it does provide a descendant <desc>, return the
description text of the first descendant <desc> element as a flat
text string, unless the element is marked (role="presentation" or
role="none").
Rich Schwerdtfeger
Attachments
- image/gif attachment: 22304624.gif
Received on Tuesday, 19 May 2015 12:43:36 UTC