W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2013

Re: SVG Accessibility

From: Doug Schepers <schepers@w3.org>
Date: Thu, 15 Aug 2013 22:13:16 +0000
Message-ID: <520D5271.4080301@w3.org>
To: James Craig <jcraig@apple.com>
CC: John Foliot <john@foliot.ca>, 'Charles McCathie Nevile' <chaals@yandex-team.ru>, public-html-a11y@w3.org, 'Jeanne Spellman' <jeanne@w3.org>, 'Jan Richards' <jrichards@ocadu.ca>
Hi, James–

On 8/15/13 5:58 PM, James Craig wrote:
> On Aug 15, 2013, at 2:50 PM, Doug Schepers <schepers@w3.org> wrote:
>> On 8/15/13 5:35 PM, James Craig wrote:
>>> On Aug 15, 2013, at 12:24 PM, Doug Schepers <schepers@w3.org>
>>> wrote:
>>>> On 8/15/13 1:07 PM, John Foliot wrote:
>>>>> James Craig wrote:
>>>>>>>>>> 3. @longdesc is inappropriate for SVG graphics.
>>>>>>>>>> Make the SVG DOM
>>>>>> accessible instead.
>>>> This may be a misleading statement. We have to look at
>>>> different scenarios to assess its truth value.
>>>> If an SVG is referenced from an <img> element […] its DOM is
>>>> not available,
>>> That's not true. Rendering engines load the DOM in order to
>>> display it, so rendering engines can (and WebKit does) make that
>>> DOM accessible whether it's inline SVG or referenced from an IMG
>>> element.
>> Interesting. I knew the DOM was there internally, but how is the
>> DOM exposed to users? Can you get to it through script?
> The rendering engine's internal model is exposed to the accessibility
> APIs. I don't think an author can get to the SVG DOM through
> JavaScript if that's what you're asking, unless it's through a
> shadow-DOM-like interface, which I have not tested.

Okay, that makes sense, thanks for the explanation.

I feel that if the DOM is exposed this way, it should also be exposed to 
Javascript, and to apps like ChromeVox.

I guess this is one of those things that we'll need to test and define.

Received on Friday, 16 August 2013 13:52:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:27 UTC