W3C home > Mailing lists > Public > public-i18n-core@w3.org > April to June 2016

Re: SVG labelling issue with ARIA

From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
Date: Thu, 21 Apr 2016 22:45:41 +0100
Message-ID: <CAFDDJ7y1QCWihCuit7wLCpyZKzQgkWZbVQ4hX7fXJCOnUVx=FQ@mail.gmail.com>
To: "White, Jason J" <jjwhite@ets.org>, Chaals McCathie Nevile <chaals@yandex-team.ru>
Cc: intlcore <public-i18n-core@w3.org>, SVG public list <www-svg@w3.org>, ARIA Working Group <public-aria@w3.org>
I really don't see this as an issue for SVG specifically.  As Jason says,
SVG (and the SVG Accessibility API Mapping spec) should solve this problem.

Ideally, you would not be using aria-labelledby in this case, you would be
using the native labelling mechanism as defined in SVG and SVG-AAM.  Adding
aria-labelledby pointing to a <title> is currently an unfortunate hack
required to deal with browsers who do not support <title> natively.

Yes, it's unfortunate that this fallback hack can't "polyfill" the new SVG
multilingual title-switch functionality, but the multilingual title switch
was designed to have a simple SVG 1.1 fallback anyway: use the first
<title> element.  So if you are going to add the redundant aria-labelledby
attribute for fallback support, it should point to the first <title>.  That
way, screen readers get the same text as visual users with tooltips on a
browser that doesn't support the new feature (currently all of them).

Hopefully, browsers will implement both the multi-lingual title/desc
behavior and proper SVG accessibility mappings together in the near future,
and this ceases to be an issue.

Now, a secondary question is whether ARIA should implement its own general
mechanism to provide multiple translations of alternative text.  But that
would need to use a different mechanism than just a list of values in
aria-labelledby, which already has a valid meaning.
Received on Thursday, 21 April 2016 21:46:14 UTC

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