W3C home > Mailing lists > Public > public-svg-a11y@w3.org > June 2015

Re: WAI-ARIA Graphics Module

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Mon, 22 Jun 2015 09:23:02 -0600
Message-ID: <CAFDDJ7x_P=r+mvPbyQf3JrxRzWgdKymSA8efKb_+JRDJxm-SaQ@mail.gmail.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
Cc: public-svg-a11y@w3.org
Thanks for the feedback Rich.  See responses below.

On 22 June 2015 at 07:04, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

> Hi Amelia,
> Thank you for all the great work. A few comments.
> 1. If you want to change the definition of the "img" role because we have
> new roles called "symbol" then we are directing authors to do something for
> ARIA in HTML today. My recommendation would be that symbol be moved to the
> main ARIA core spec. to differentiate the two.
> http://rawgit.com/w3c/aria/master/aria/aria.html#img

I'm fine with that if there is support for it in the main ARIA team.  I
think it really comes down to timing, and which spec will be ready when.

> 2. The HTML Figure element is currently mapped to a "group" or panel role
> in platform accessibility APIs.
> http://www.w3.org/TR/2015/WD-html-aam-1.0-20150407/#el-figure
> Your definition of figure also refers to a caption. That is fine but there
> needs to be a distinct relationship between the caption an figure it is
> labelling.
> http://www.w3.org/TR/2015/WD-html-aam-1.0-20150407/#el-figcaption
> Because we are not introducing new elements that are known to be directly
> associated we need to be able to associate a label with the figure. We
> could define a figcaption role that requires that labels  a figure. If we
> want to do this we should also consider putting it in the core ARIA spec.
> I was assuming that aria-labelledby would cover the figure/caption
association, without needing a special role.  The HTML guidelines treat
<figcaption> as an element with native semantics for defining the label of
the figure.  The same for a table caption.  In that way, it is similar to
SVG <title> and <desc>, except that a <figcaption> is visible text.

Regarding the existing default "group" mapping, I think that is the same
problem we had with the SVG default mappings -- mis-using "group" because
there was nothing else suitable.  I don't know why "region" wasn't used; I
would assume that it is closer to the "panel" role in OS APIs.

Maybe you could ask around, and if there was a clear reasoning behind *not*
using "region" for figures, we could change the parent class and suggested
fallback for "figure".

> 3. Graphicaldoc would appear to be a superclass of chart, map, etc. and
> not a subclass. I see that graphical characteristics are missing from
> graphicaldoc. This should subclass either the "region" or the "group:
> roles.

That's what I meant: charts and maps are sub-classes of graphicaldoc.  If I
wrote the reverse, it was an error.  I'm up to suggestions for the parent
role; I had it extending the basic document class, but region also works.

> 4.  Regarding dropping the g- that will be a non-starter unless it goes
> into the ARIA spec. It is possible that other taxonomies could run into
> naming conflicts so we have an ARIA Extension model:
> http://www.w3.org/WAI/PF/wiki/ARIAExtensions
> We already had this discussion with the ARIA digital publishing effort and
> this was the extension strategy that we all reached consensus on. Let's
> take figure for example. A figure could mean something entire different in
> the fashion world. We have to ensure we do not have name conflicts. So, if
> you would like a different vocabulary preamble, say graphics-, that makes
> more sense then I would be open to that but we need to avoid name
> collisions.
That makes sense; thanks for the link.  However, it makes it more difficult
to work on these roles separately but plan to eventually them into the main
ARIA spec (for ARIA 2 or a future edition).  I suspect the figure,
iconbutton, and symbol roles,  would all be of broader use.  Just speaking
as an author, I would find it rather arbitrary and difficult to remember
which roles have a g- in front and which don't.

We could put the prefix back in for now, get everything cleaned up for a
working draft, and then reach out to the rest of the ARIA team to see if
they have any interest in "poaching" our definitions and pulling them into
the main spec, minus the namespace prefix.

Received on Monday, 22 June 2015 15:23:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:28:16 UTC