- From: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
- Date: Wed, 14 Sep 2016 15:42:31 -0600
- To: Anne van Kesteren <annevk@annevk.nl>, Alexander Surkov <surkov.alexander@gmail.com>
- Cc: ARIA Working Group <public-aria@w3.org>, Richard Schwerdtfeger <richschwer@gmail.com>, SVG-A11y TF <public-svg-a11y@w3.org>
- Message-ID: <CAFDDJ7wXvNzCQfPbcsXT7wrVNw=-TS8aC14Au62oEOFaPccNSw@mail.gmail.com>
To clarify: SVG does not, and has no plans to, allow arbitrary semantic HTML content inside SVG files. There are only three valid ways to use HTML inside SVG: - In a user agent that supports HTML, an SVG `<foreignObject>` allows you to inject a container of CSS-styled HTML content. However, this affects much more than just semantics. Theoretically, you can have another inline SVG inside that HTML, but the layout would be quite different than without the foreign object markup. Furthermore, it has no effect in SVG user agents that don't support HTML. - To improve fallback in browsers that don't support SVG, the SVG metadata elements (title, desc, and metadata) allow foreign-namespace content, including HTML markup. These have neither visual nor semantic effect on the SVG document. - SVG 2 allows a limited set of HTML embedded-content elements to be used in SVG: canvas, video, audio, and iframe. This is not yet supported in browsers or the HTML parser. Creating ARIA roles which are directly paired with HTML semantic elements seems to me like the definition of avoiding duplication of efforts. Instead of creating a new semantic language, we would be making the existing HTML semantics available as annotations to any XML document. In addition to SVG, this could be relevant in other languages where the markup describes layout rather than semantics, such as XSL-FO. On 14 September 2016 at 02:45, Anne van Kesteren <annevk@annevk.nl> wrote: > > The SVG accessibility effort does not want to piece part chunks of host > language elements in the middle of an SVG document which needs to stand > alone. Not all SVG documents are embedded in HTML. So, sticking an HTML > figure element inside of an SVG document is a non-starter. > > This seems diametrically opposed to the efforts of the SVG WG, who no > longer wish to duplicate HTML efforts and are working on making it > easier to use both together. I don't understand why the SVG > accessibility effort would chose a different direction from the SVG > WG. > On 14 September 2016 at 14:14, Alexander Surkov <surkov.alexander@gmail.com> wrote: > > I buy the argument that you may need HTML figure semantics in SVG, I'm not > yet sure that ARIA has to be extended to address it, because HTML already > has <figure> and it can be reused in SVG document. See Anne's answer on > this thread [1]. > >
Received on Wednesday, 14 September 2016 21:43:01 UTC