- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 15 Aug 2013 22:13:16 +0000
- 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. Regards- -Doug
Received on Friday, 16 August 2013 13:52:11 UTC