Re: Accessible name on SVG and the G element

Thank you Chaals for your wisdom.

I will certainly look at, and bookmark for further reading that Github resource.

Thank you for your DIV to G element comparison. Even though a G element carried no semantics, simplistically I assumed a screen reader would traverse all the content of an SVG and would respect each ARIA-LABEL it encountered even if it were on a semantics-free element; but I know too little to rely on this assumption.

I am sure your characterization of my idea about using JavaScript as 'fragile' is correct. I was almost thinking out loud; just wondering if I can make a suggestion to my client for a sticking-plaster solution since they are using, I believe, a library that builds the SVG based on a data source, so I suspect they have little control on the construction of the SVG. Unless they make larger changes to their process.

It sounds increasingly as if I will not be able at this point to provide a good and simple "fix" that will allow the current solution to simply become accessible.

All feedback here has been very helpful for me to report back to them about this issue and perhaps they will consider abandoning the current code that builds their SVG and look at the Github resource in case one of its components may be employed to provide an accessible SVG.

Regards,

Alan
. . . . -   . . - - -
Alan Bristow ( he / him / il )
Web Developer / Développeur Web
Elections Canada / Élections Canada
alan.bristow@elections.ca
+1 873-416-1175

________________________________________
From: Charles 'chaals' (McCathie) Nevile <chaals@yandex.ru>
Sent: Monday, June 20, 2022 9:53 AM
To: w3c-wai-ig@w3.org
Subject: Re: Accessible name on SVG and the G element

Ce message a été envoyé par un expéditeur externe. Veuillez faire preuve de prudence et ne pas cliquer sur les liens ou ouvrir les pièces jointes à moins de reconnaître l'expéditeur et de savoir que le contenu est sûr.

This message was sent from an external sender. Please exercise caution and do not click links or open attachments unless you recognize the sender and know the content is safe.

On Mon, 20 Jun 2022 15:16:42 +0200, Bristow, Alan
<Alan.Bristow@elections.ca> wrote:

> I have yet to try out Bryan's suggestion of foreignObject element.

It doesn't sound like that matches your use case.

>> you can use ARIA to add table structure if that's relevant
>
> Thank you Chaals , I can see there is a lot to understand and a lot of
> potential that is likely beyond my influence in the case I am looking at.
>
> Thank you Léonie, I am not too surprised to find my optimistic overly
> simple suggestion would be insufficient in some cases.
>
> Until I can rely on screen readers discovering ARIA in <g> elements I
> assume a solution, to my case at least, needs to assume those items will
> be missed and provide a work-around.

Screen readers handle a certain amount of ARIA, but they expect it to
match certain conditions.

A g element in SVG is a bit like a div in HTML - it has no meaning so
there is no a priori reason to assume it's important.

If things have roles that match things screen readers interact with, I
think you'll have better luck.

> I will do some experiments, with foreignObject and perhaps with having
> JavaScript duplicate the "invisible" <g> aria to a visible element and
> then removing the <g> aria (so it is not read twice in cases where a
> screen reader *can* discern the <g> element aria.

I would go far to avoid the second experiment - it sounds like a very
convoluted and fragile approach.

I do suggest you have a look at
https://github.com/SVG-access-W3CG/use-case-examples (pick the things that
have fles accompanyng called "whatever-name-notes.html" and then things
that have a comment *other than* "added files for playing with..."

That repository has a number of SVG things, and the idea (which only
happened a little bit) was to take the examples and work on how to make
them more accessible. They're not necessarily perfect, but there are some
ideas that are implemented because we expected them to work, sometimes
they did, and sometimes we even wrote some notes about what we did and how.

If you're looking at presenting data, it's close to most of what I was
interested in at the time, and there are some reasonable techniques you
can successfully use.

> New to trying to understand SVG properly, I am surprised its a11y
> support is so nuanced and not yet fully baked (if that is not too unkind
> a description.).

screen reader support for a highly flexible powerfu graphics format is a
nuanced idea - and when you build it on an ecosystem that was designed
around structured text, even more so.

But yes, I am sad that the evolution of this has been so slow. But there
are a number of people around who know this stuff in the current state of
the art...

(And I "reactivated" the group, as if I will have some time to work on
this in the next few months. Although if others are, I might go along for
the ride and see what I can contribute).

cheers

> Regards,
>
> Alan
> . . . . -   . . - - -
> Alan Bristow ( he / him / il )
> Web Developer / Développeur Web
> Elections Canada / Élections Canada
> alan.bristow@elections.ca
>
> ________________________________________
> From: Léonie Watson <lwatson@tetralogical.com>
> Sent: Saturday, June 18, 2022 8:39 AM
> To: Bristow, Alan; w3c-wai-ig@w3.org
> Subject: Re: Accessible name on SVG and the G element
>
> It likely depends on the number of <g> elements and their purpose. If
> each <g> element is an object worthy of its own accessible name, I'd
> hazard a guess that concatenating them altogether into a single
> accessible name for the <svg> element probably won't work well for
> screen reader users.
>
> If you had an SVG representing the notes in an octave for example, each
> <g> element that represented a note might have an accessible name of
> "C", "D", "E", and so on. An appropriate accessible name for the SVG
> would not be "C, D, E..." though, but something more like "Scale in C
> major".
>
> So the deciding question is probably whether the SVG represents a single
> image that can have a single accessible name, or if it's a composite of
> multiple images that each need an accessible name.
>
> Léonie.
>
>
>
>
>
> On 17/06/2022 15:03, Bristow, Alan wrote:
>> Thank you Léonie,
>>
>> We do have role="img" on the SVG, but not on the G; MDN says it *can*
>> be used on the G.., but perhaps it is only beneficial when used on the
>> SVG..?
>>
>> As for the Gs being buried deep in an SVG, sadly yes they are
>> : (
>>
>> Given:
>>
>>> if the <g> element is buried within a more complex SVG the results are
>>> a lot less certain.
>>
>> it seems the practical solution, today at least, is to avoid relying on
>> aria-label on G elements, and use an alternate method, my go-tos would
>> be:
>>
>> 1. aria-labelledby on the svg
>> 2. concatenating the texts that *would* have been in the G aria-labels,
>> into a single aria-label on the SVG
>>
>> Regards,
>>
>> Alan
>> . . . . -   . . - - -
>> Alan Bristow ( he / him / il )
>> Web Developer / Développeur Web
>> Elections Canada / Élections Canada
>> alan.bristow@elections.ca
>>
>> ________________________________________
>> From: Léonie Watson <lwatson@tetralogical.com>
>> Sent: Friday, June 17, 2022 8:46 AM
>> To: Bristow, Alan; w3c-wai-ig@w3.org
>> Subject: Re: Accessible name on SVG and the G element
>>
>> You can use aria-label on a <g> element but you'll also need to use
>> role="img". Otherwise, the label will not be recognised.
>>
>> You'll also want to do some thorough browser and screen reader testing.
>> In isolation a <g> element with these ARIA attributes will likely be
>> well supported, but if the <g> element is buried within a more complex
>> SVG the results are a lot less certain.
>>
>> Léonie
>>
>>
>>
>> On 17/06/2022 14:02, Bristow, Alan wrote:
>>> Hi,
>>>
>>> Due to no (in my very limited experience) screen reader support for
>>> ARIA-LABEL on the G element (inside the SVG element), I am considering
>>> concatenating all label info from G elements into one "sentence" for
>>> the content of the ARIA-LABEL on the SVG element. It seems an
>>> ARIA-LABEL on the SVG element IS read out.
>>>
>>>
>>> Background
>>>
>>> There are lots of articles on accessibly naming SVGs. I don't think
>>> I've seen one that explicitly uses ARIA-LABEL with the G element, or
>>> says not to, but I see that it is a valid attribute
>>> https://developer.mozilla.org/en-US/docs/Web/SVG/Element/g#aria_attributes
>>>
>>> A JavaScript library my client is using to help the automated build of
>>> SVGs from data, is producing SVGs with G elements, each G element with
>>> an ARIA-LABEL, yet my AT (NVDA+Chrome+Win10) plus one or two I've read
>>> about, are not reading those ARIA-LABELs. Changing nothing except
>>> hand-editing so an ARIA-LABEL is on the SVG element results in that
>>> ARIA-LABEL being read out.
>>>
>>> Does anyone know about this?
>>>
>>> (I hope this is sufficiently a11y focused to be allowed here).
>>>
>>> Thanks in advance
>>>
>>> Regards,
>>>
>>> Alan
>>>
>>> . . . . -   . . - - -
>>> Alan Bristow ( he / him / il )
>>> Web Developer / Développeur Web
>>> Elections Canada / Élections Canada
>>> alan.bristow@elections.ca
>>
>> --
>> Director @TetraLogical
>> https://tetralogical.com
>>
>
> --
> Director @TetraLogical
> https://tetralogical.com


--
Using Opera's mail client: http://www.opera.com/mail/

Received on Monday, 20 June 2022 14:31:38 UTC