There has been a heated argument recently on the W3C Canvas API mailing list between accessibility advocates and browser vendors over a pretty tricky topic: should the Canvas API have graphical “objects” to make it more accessible, or should authors use SVG for that? I think it’s a false dichotomy, and I offer a proposal to suggests a way to improve the accessibility potential of the Canvas 2D API by defining how SVG and the Canvas 2D API can be used together.

This brings together some ideas I’ve had for a while, but with some new aspects. This is still a rough overview, but the technical details don’t seem too daunting to me.

Retained-Mode vs Immediate-Mode Graphics

First, some background…

SVG is a retained-mode graphics format, meaning that each shape persists as a separate object, with distinct characteristics such as location, size (bounding box), and precise outline (stroke). These characteristics can be acted upon within the object structure (DOM) as discrete entities (or groups of entities) for manipulation by script or by user-interface actions (e.g. mouse clicks or keyboard tabbing); one of these interactions may be hit-testing.

The Canvas 2D API is an immediate-mode API, meaning that it allows the programmer to create visual shapes as individual pixels that are unstructured; in other words, if a red circle and a red square are drawn which overlap one another, there is no way to distinguish these from one another, or from the background canvas element (though a programmer could maintain a separate structure in script).

With retained-mode graphics, each object which is added to the DOM increases the memory “weight” of the page or application, potentially slowing down the browser or otherwise decreasing performance; by contrast, immediate-mode graphics, which are not represented as objects in the DOM, do not decrease performance, which is an advantage over retained-mode graphics.

Some accessibility advocates have noted that hit-testing and zooming are critical accessibility features of graphics; this requires the ability to access the location, size, and other characteristics of individual graphics. Unfortunately, adding this retained-mode feature to an immediate-mode API effectively removes the primary advantage of using an immediate-mode graphics system.

However, by defining how SVG and the Canvas 2D API can be used together, a model may be created which allows authors to easily use both together, each for their appropriate strengths. This approach involves two aspects: defining the behavior, and a potential shared API syntax.

Defining Behavior

Currently, the Canvas 2D API is only defined to work with the <canvas> element defined in HTML5, and it does not allow SVG to be drawn or imported into the Canvas. However, it could be extended to work inside SVG or to allow SVG to be used inside Canvas.

Canvas in SVG

At its simplest, the Canvas 2D API could simply be defined to allow authors to draw on the SVG raster <image> element, just as it does in the HTML <canvas> element, but there does not seem to be a reason to limit it to this element. The Canvas API could be defined to draw to any SVG element, rendering or structural, as an overlay. It would be merely a visual effect, and would participate in the rendering structure, including “z-index”, only as its “target element” does.

SVG in Canvas

SVG shapes could be allowed to be imported into the <canvas> drawing context, such that they render there but are also inserted into the DOM or shadow DOM. Currently, as I understand it, this is not allowed for security restrictions involving content from potentially different sources, but for content that does not have external references (for example, a <use> element to another site, this should not be a security risk.

SVG in the Shadow Tree

The accessibility features of the Canvas 2D API include a “shadow tree” and focus ring for those elements, such as text, which are not otherwise accessible to users with limited vision. Each such “graphic piece” which is created and painted to the screen is also represented in this underlying shadow DOM (IIRC).

SVG elements used in conjunction with Canvas could also be placed in this shadow tree, so that navigability is preserved. In order to save memory usage, a concept like the <use> element in SVG could alternative be used to “point to” an SVG in the main DOM from its appropriate place in the shadow tree.

SVG elements could either be used as visual shapes themselves, or could be invisible “hot-spots” for specific areas of the screen.

Common API

I have suggested before that we create a simple graphics API that will allow either 2D Canvas (immediate-mode) or SVG (retained-mode) images with the same set of methods and parameters, with the only difference being which “mode” the author selects to have as the instantiated form. If the author draws a circle to the canvas context, it would simply be drawn to the screen with no structure; if the author draws that same circle to the SVG context, it creates a <circle> element with the appropriate attribute values and style and inserts it into the DOM.

There would be certain differences in some of the renderings, because of the different rendering and compositing models of SVG and Canvas, and there would be certain specialized functionality and features each would have, but the majority of the visual appearance would be the same.

This would allow authors to learn only one API for 2D graphics for the Open Web Platform. With this ease of learning and use, the author could decide on a case-by-case basis, even within the same application, which mode works best. It would provide incentive to authors to use each to its best effect.

I call this approach COG: Common Open Graphics.

Example

An example of the effective use of SVG and Canvas together is a hypothetical game in which the user pilots a spaceship amidst an asteroid field.

The background of the game includes animated nebulae, passing comets, rotating planets and moons, and other visual effects which are not interactive, and which do not affect the play of the game, but which add visual appeal. The foreground of the game (the “playable area”) includes asteroids, enemy ships, and energy beams that the player must dodge or shoot at, which increase in size the closer they get, and which benefit from hit-testing and keyboard focusability. The middle-ground of the game contains many smaller asteroids and ships that are not yet interactive, and so don’t need hit-testing or focusability.

Adding all of these graphics shapes as retained-mode objects in the DOM would unnecessarily increase the memory footprint of the game, degrading performance and playability. However, since only a small number of these elements (those in the playable area) need the retained-mode interactivity, the majority of them could be drawn with immediate-mode characteristics, then when a certain “distance threshold” is reached, changed to interactive SVG elements, perhaps using the same shared API. This preserves the accessibility of the game, while also causing minimal performance degradation, and possibly even helping performance, since the hit-testing doesn’t need to be calculated in script. From an authoring point of view, using the same shared API means that both types of shape, retained-mode and immediate-mode, are equally easy to generate and maintain.

To enhance the visual appearance of the SVG asteroids, the finer control of the Canvas API could even draw an overlay on the SVG stroke and fill areas, much as filters do, to show craters and other surface details in a more fine-grained manner then can be done efficiently in SVG. Since this would be drawn specifically on the SVG element, the element itself would still provide the geometry and position characteristics.

Caveats

This proposal has two caveats:

1. Canvas can only be extended to be as accessible as SVG is, in this model. Even with object retention, there are still many enhancements needed to make SVG truly widely accessible. However, as plans for SVG accessibility improvements are made, these would be largely importable directly into the Canvas API, rather than working in parallel on two unrelated but overlapping graphics models.
2. Simply because the Canvas 2D API may be made more accessible, does not mean that all Canvas API applications or content will be automatically accessible, any more than all HTML or SVG content is accessible. Authors will still need to use best practices and take specific steps to make their applications accessible. This proposal only provides the means and the incentive to do so.

Feedback

I’m interested in feedback on this, either in the comments section of this blog, or on the W3C Canvas mailing list, public-canvas-api@w3.org.

Update

Someone pointed out offlist that this post emphasizes the accessibility aspect of this proposal, because that was the context of the most recent discussion, but this is a win for anyone who wants to do graphics in the browser, for any reason, not just accessibility. Like any good accessibility feature, my proposal has general benefits, so it is more likely to be used in more content. In the example scenario above, the developer gets the hit testing for free, regardless of whether or not Accessibility Technology is involved. Other general advantages include ease of learning and use of graphics by developers (as mentioned above), sharing of features between modes (like using Canvas.toDataURL() to save an SVG as a PNG), pixel operations (like painting or detecting a color at a point) in SVG, metadata (like microdata, RDFa, or microformats) in select parts of a Canvas app, and so on. I’m sure that clever people will come up with a whole boatload of cool things to do with a combined retained-mode/immediate mode API that I couldn’t imagine here.

Text in SVG is text. Visually, you can use webfonts like WOFF or SVG Fonts (where they are supported, like in Opera or the iPhone) to make it look cool, and you can style both the stroke and fill to make it all fancy, or apply filters to pop it out or make it glow or give it a dropshadow, but it’s not just a raster image like many text headers… it’s human- and machine-readable text, as nature intended.

So, SVG is translatable, right?

I wanted to make that point in my talk yesterday at Web Directions East, here in Tokyo, so I thought I’d translate my slide on text in SVG
in real time (note: click the down arrow to step through the bullet points). But testing it beforehand (I’m glad I did some prep), neither Google nor Bing even try to translate it. Yahoo’s Babel Fish at least returns the original page, though it doesn’t take the extra little step of doing any actual translation.

Lame.

Why don’t they translate it? Bing offers this helpful explanation:

What text formats are supported?
Html and Text. The viewer will not translate text on images, in PDFs, or in Flash graphics and animation. It may also not translate some dynamically generated text, such as in cascading menus.

I expected this to work, since Google now indexes SVG; as I mentioned in a previous blog post, I made a test page back in 2002 that sorta conflated the two services, indexing and translating. But obviously, these are two different tools, and need to be fixed separately.

It would be easy to fix, I’d expect… simply add SVG to the list of allowed file types, and translate the text content of each element, just as they do with HTML. If they actually special-case different element types, that would add slightly more work, but not a lot… just as with the task of indexing, you would pay attention to the content of the <text>, <tspan>, <textPath>, <title>, and <desc> elements.

It’s ironic that this doesn’t work, because on my way back from Lyon last week, I happened to meet Bert Esselink, the author of a book on localization who works for the translation company Lionbridge, and he and I chatted about how they use SVG extensively for their translation work.

In the end, I just had a native speaker translate a couple of text passages (the automatic translations were apparently not very good) and included them in my slide, just to serve as a placeholder. But I’m hopeful that soon I can demo the automatic translation live. It would be especially useful to people looking at SVG infographics, to be able to see charts and graphs in their native tongue.

Dramatis Personae

• Doug Schepers (a Montague)
• Anne van Kestern (a Capulet)
• Simon Pieters (a Capulet)
• Henri Sivonen (a Capulet)
• Rich Schwerdtfeger (a Franciscan)
• Aaron Leventhal (an Apothecary)

The Prologue

Over the past few weeks, there has been a long, drawn-out discussion about how to integrate ARIA (an accessibility specification) into both SVG and HTML in a uniform way. There have been two main camps, as there usually are in these matters: the XML advocates, and the HTML5 (WHATWG) advocates. Both sides want to make sure that all content works the same across all browsers, authoring tools, etc. (collectively called User Agents), but they differed in how they thought it should be done.

The XML True Believers have held that the way forward for the Web is to enforce a strict, well-defined syntax for Web languages, and that to extend or combine languages, a differentiating mechanism called “namespaces” would be used. Namespaces in XML are specified to take the form “schepers:doug”. They declared a do-over on HTML, recasting it in the new XML mold (XHTML), and planned for browsers to be stricter on new content, and for authors to have learned their lessons.

The HTML Young Turks came forward with the observation that no matter how well you define a syntax, people will make mistakes (or not know the right way to do things), and that the way to recover from those mistakes is to define error-handling behavior for each kind of mistake; they also believed that since they could now reconcile older “broken” content with new browser behavior, that they were constrained to define behavior that would work in all past browsers, as much as possible, and to degrade gracefully in those that didn’t. But this required a more rigid parsing mechanism that doesn’t work well with extensibility, a problem exacerbated by Internet Explorer’s idiosyncratic and variable (one might even say spasmotic) behavior regarding the colon (“:”), meaning XML Namespaces didn’t work right. Also, the colon has a special meaning in CSS, yet another wrinkle.

So, XHTML and SVG are based on the XML model, and the new HTML5 is based on the new-old model. This difference wasn’t really much of a problem for SVG, though, because SVG and HTML are two different languages…

But of course people want to use them together. (More on that in some other post.)

The obvious way around that is to have two different parsers (a parser is a program that reads a formal syntax and makes a model of it for the browser to act on), and when you encountered SVG inside HTML, you would switch to the stricter parser. HTML would have its model for naming attributes (with no colon), and SVG would have its attributes (with a colon).

But there’s a hitch. ARIA is an accessibility technology meant to work in HTML and XHTML and SVG (and other presentation languages). The functionality for ARIA is defined in its own specification, but it’s not intended to be used on its own… it has to be integrated into a host language. It would be confusing for authors to have to use two different syntaces for the same functionality in different languages.

For example, in SVG you might have:

<svg version="1.1"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:aaa="http://www.w3.org/2005/07/aaa">

<g xhtml:role="checkbox" aaa:checked="true">
<rect x="5" y="5" width="20" height="20" rx="5" ry="5"
fill="none" stroke="crimson" stroke-width="2"/>

<text x="30" y="22" font-size="18" fill="crimson">
Enable Accessibility</text>
</g>

</svg>

While in HTML, you would have something like:

<html>
<ul role="checkbox" aria-checked="true">
<li>Enable Accessibility
</ul>
</html>

Let the drama unfold…

Act I

Scene I

XHTML defined a new point of extensibility, the ‘role’ attribute, which was intended to be use to add semantics to an element.

Scene II

The WAI Working Group decided to use that as the point of entry for adding accessibility behaviors to custom controls. Custom controls are things like an interactive tree selector, or a slider knob; they extend the limited set of form-based controls that browsers settled on, and they are increasingly used in script libraries like dojo or Scriptaculous. SVG developers have been making custom controls using script and/or declarative animation for many years, since SVG doesn’t have any native controls at all, but can be used to build visually glitzy ones; they just aren’t treated as controls by AT (Assistive Technology) apps. ARIA can be used to tell the AT that a collection of elements is meant to represent a particular type of control, and report what its current state is (on, off, hidden, selected, etc.). So the SVG WG has been eyeing the progress of the Role and ARIA specs.

Act II

Scene I

The HTML5 movement, under the banner of the WHATWG, gained critical mass and was brought into the W3C for standardization with all major browser vendors. The ARIA proponents worked hard to get ARIA’s accessibility functionality integrated into the standard. Simon Pieters of Opera and Aaron Leventhal of Mozilla made a proposal for integration of ARIA using a limited ‘role’ attribute. Because XML Namespaces don’t work right in IE (and not very intuitively in CSS), it was proposed that the different states of ARIA would be referenced and set in HTML5 using the prefix ‘arai-*’ instead of ‘aaa:*’ or ‘aria:*’. I was only vaguely aware of early discussions of ‘role’ in HTML5, and despaired of its ever being adopted, knowing the resistance to generic extensibility. But Simon and Aaron were actively working on getting ARIA integrated into the next releases of Opera and Firefox, to enable accessible Web apps.

Scene II

Dave Raggett (who originated forms in HTML) made an independent public request for the ‘role’ attribute to be added to SVG; I jumped on this, expecting that it would be done using the built-in extensibility mechanism provided by XML Namespaces. Much to my dismay, immediately was made aware of Simon and Aaron’s proposal, which uses different syntax to how it would be done in SVG. Much email discussion ensued, and a little biting of thumbs.

Scene III

I talked with the SVG Working Group about the ‘role’ attribute (step one in integrating ARIA), and while there were some reservations, we agreed that it would be great if we could do it. (Note: really boring issues of process elided here… assume I explained why it’s kinda bad timing for SVG right now.) But we decided to first gather opinions about how best to do so from the SVG community and other interested parties. But the issue of ‘role’ was buried under the talk of whether or not to use the controversial and dreaded Namespaces (e.g. ‘aria:checked’ versus ‘aria-checked’). It’s undesirable to add arbitrary attributes to SVG, because the content wouldn’t validate and couldn’t take advantage of all the XML tools that already exist. And there are like 70 attributes, so we couldn’t just adopt them all… and if we did, what would happen when ARIA v2.0 came out? Ugh… messy. But the HTML5 guys insisted they couldn’t use namespaces.

Act III

Scene I

Rich Schwerdtfeger of IBM, who’s heavily invested in getting ARIA implemented, set up an informal call involving the Dramatis Personae (and a few others who couldn’t show up). I talked it over with people on “my” side, and reviewed the XML Namespaces specification. A little reflection revealed to me that, in fact, both approaches were using namespaces… just the syntax is different (‘aria:*’ versus ‘aria-*’). And while the Namespaces spec doesn’t describe any other mechanism than the namespace declaration and prefix, neither does it procribe it. I saw a possible way out.

The uninformed reader will assume this is some persnickety, trivial detail; such a reader would be right, but it’s still a pain to coordinate on crap like this. Everyone assumes they are right, the other guy is wrong, and everyone should just do it their way.

Scene II

The teleconference happened today, and arguments were presented, and assumptions were challenged, and a verbal duel took place. Issues with delimiters in IE and CSS were explained and explored. The colon was a real problem, but so was the dash. Making the “aria-*” string is a klutzy, short-term, one-off solution, and couldn’t really cut it as a true namespace prefix. SVG has many attributes that contain the dash (‘stroke-width’, ‘fill-rule’, ‘font-size’, ‘stroke-dasharray’, ‘fill-opacity’, ‘pointer-events’, ‘font-family’, ‘shape-rendering’, and many more); it’s a common convention to separate words in attributes with a dash. No future (or present) language could safely use ‘font-’ or ‘shape-’ or any other prefix to integrate with SVG.

But Aaron Leventhal, a very pragmatic guy, pulled out just the medicine I think was needed. The underscore (“_”). It works in IE, has no special meaning in CSS, is a legal (if underused) character for attributes in XML, doesn’t cause problems for the HTML parser, and doesn’t conflict with any conventions in SVG. It’s probably underutilized because it’s just slightly harder to type than a dash (on my keyboard, it’s the same key, but requires the shift key be depressed).

_!!

Scene III

The final scene has been lost in the mists of the future. But here’s my plan, if nothing gets in its way: to create a new namespacing specification that uses the underscore as its prefix delimiter. It would differ from Namespaces in XML 1.0 in three ways:

1. It would make the namespace prefix string fixed. In XML Namespaces 1.0, any string is allowed to be used for any namespace prefix. For example, if you were feeling particularly contrary, you could delare that the string “svg” is the prefix for XForms content, “xforms” is the prefix for MathML content, and “math” is the prefix for SVG content; in reality, nobody does this, for obvious reasons. In my proposal, there would be a central “registry” of sorts for the most common prefixes; my suggestion is that such a registry should be defined in the CDF WICD profiles (though I haven’t consulted that group), and that a User Agent that supports multi-namespace documents (aka Compound Documents) would know what those prefixes stand for. The most obvious ones are “svg”, “html”, “xhtml”, “xforms”, “mathml”… oh, yeah, and “aria”. That this is less inherently extensible than the colon-delimited unfixed prefix might even be a bonus, ensuring that the combination of technologies has been combined systematically and specified, promoting interoperability betweem UAs. Prefix names would consist only of letters and digits, forgoing the dot and the dash, and of course the colon and underscore; a possible exception that occurs to me is the use of the dot to serve as a versioning convention, so you would have “aria.2_checked” to represent an ARIA v2.0 ‘checked’ attribute.
2. As a consequence of #1, there would be no declaration needed or specified. The supporting UA would simply know the ” name + _” prefix, and treat it as it should be treated. This makes copy-paste authoring easier, since authors wouldn’t have to know or care about the namespace declaration earlier in the scope of the copied content.
3. This specification would not reserve the underscore, but merely allow supporting implementations to assign special meaning to the combination of ” name + _”. This would prevent some problems in existing XML processors. Languages that register their prefix name would be encouraged to pick something that is unlikely to conflict with other partial attribute or element names. (I toyed with the idea of making this an extension mechanism for attributes only… not element names. I haven’t thought that through yet, though.)

This would be more intuitive for creatinging documents, since authors (and authoring tool) could depend upon a convention. Supporting XML processors would have a much easier time resolving namespaces. Languages and UAs could support both namespacing schmemes, if they so chose, to allow for custom or unconventional namespaces that aren’t registered; the two schemes are orthogonal and (I believe) compatible.

Let the rotten tomatoes fly.

In addition to geometric shapes, SVG has advanced graphical text capabilities. In SVG 1.1, there are several elements specifically designed for the presentation of text. At the most basic level, there is the <text> element, which can have child <tspan> elements that can be positioned and styled independently of the other text content, like this:

Then there are more advanced options, like rotated text
or the <textPath> element

The future of SVG text support holds still more. In the next version of the SVG specification, SVG Tiny 1.2, there are even more useful text features, like the <textArea> element that automatically wraps text to a shape (rectangles on for mobile devices, but any shape at all in future versions of the specification). There is also the new ability to make any text editable by simply including an attribute to the text element. And there are great features from SVG 1.1 (the current version) that are not yet widely implemented, such as SVG Fonts, which let you embed a font into an SVG file so the reader sees the page the way the author intended it, and the <tref> element that lets you directly quote text without duplicating it. All these features will give more control to authors and give a better experience to users.

But is that enough?

The Study of Meaning

Semantics is the study of meaning; a cluster of dots in the shape of a word doesn’t mean anything to a machine, but real words and sentences can be connected to concepts, and that is why this is important in a graphical format like SVG. All of these text features really are text, not just images of text. They can be searched for, copied, indexed by search engines, and understood by screen readers. Screen readers are a kind of assistive technology that reads pages out loud for people with vision problems. It’s not just for people; machines like it, too. It has semantic value, and this moves us toward the Semantic Web. There is also the <switch> element, which is an excellent way to provide different text content, such as your own translations, depending on the user’s computer systemLanguage. Obviously, this adds meaning by disambiguating different possible translations that a computer-based translation might not catch (because people are smart, and computers are merely fast). And it’s not just the visible text that provides meaning, but also the metadata (or “data about data”). SVG’s <title>, <desc>, <metadata> elements are not rendered onto the screen (although the Opera browser does provide a tooltip for the title text), but can be indexed by search engines, and the use of script or special browser capabilites (such as native browser support for RDF, a special kind of markup that describes the relationship between terms used in the metadata) can provide extended functionality. As you might expect, the <title> and <desc> elements are meant to be human-readable, while <metadata> elements more frequently contain computer code.

A Semantic Argument

But in a recent post to SVG-Dev, a representative from Adobe pointed out some possible shortcomings of SVG’s text capabilities compared to HTML or PDF. Adobe is using SVG in its new Mars project, which is an XML version of their popular printable document format. Now, I don’t find HTML to have very much semantic content either (see this very long post on semantics from a couple of years ago), but Adobe’s Leonard Rosenthol points out that computers (specifically screen readers) can’t distinguish between paragraphs and columns of text, and particularly not tabular content (where each cell in a table has a context in both a row and a column). I don’t think that paragraphs or columns are particularly semantic (and certainly aren’t universal even among written languages). They are largely cosmetic print conventions, and although of course that matters for printed formats, it’s not as important for accessibility or spoken-word understanding, nor for machine understanding; although admittedly paragraphs do represent some structure (I’m having flashbacks to composition class in high school here), most often columns are simply a convenience of text flow within a constrained area and carry no distinction from one another, and where they do, it is typically simple tabular data. Tables are another matter, though, because of the specific associations involved in cell position. There are other semantic orthographic properties of documents that matter more than print conventions, and which have sometimes been passed off as merely stylistic, such as emphatic text (represented by boldface, italics, or relative font sizes) that is indicated by tone in spoken language.Acronyms, abbreviations, definitions, and quotations all have HTML representations (although they are too rarely used), and there is no equivalent of those tags in SVG (by design); but that meaning is limited to a specific knowledge domain, that of generic textual reference. There are other specific domains that have highly structured tagsets just dripping with meaning, like Chemical Markup Language (CML), Linguistics Markup Language (LGML), Music Markup Language (MML), MicroArray and Gene Expression (MAGE — contrasted with the almost inevitable Bible Markup Language)… mapping, geography, mathematics, psychology, literature, sociology, physics, architecture… every area of human endeavor has a systematic structure that is (or will soon be) encoded in some kind of tagging scheme, whether that be in the form of XML, RDF, or some other format. But these semantics are largely lost on the Web.

SVG has taken pains to avoid including specific semantics in the specification, in order to remain a neutral presenatation format. The only semantics are derived from the graphical geometry, which nevertheless can be extended to related domains like mapping and geography (and possibly feng shui). But it would be ideal if the underlying structure carried all the rich semantics of the graphical data being presented, if a circle were identified as an atom, or a rectangle were a flowchart box, if your computer knew what we know when we look at something, or even explaining it to us when we don’t know what we’re looking at. These are true problems that need a solution. How can we add semantic properties to SVG, to the Web in general?

Technical Solutions

RDF

I’ve already mentioned RDF. This is one way to add extra information to the geometric presentation. Let’s use molecules as an example (see source):

The code would look something like this… I say something like this because A) this is only a snippet and B) I’m no RDF guru and I’m sure I got something wrong:

<svg>
<line x1='840' y1='170' x2='600' y2='170'>
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="http://www.example.org/bond">
<m:atom_link rdf:resource="http://www.example.org/carbon-oxygen" />
</rdf:Description>
</rdf:RDF>
</metadata>
</line>

<g fill='gray'>
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="http://www.example.org/carbon">
<m:bonds_to>
<m:oxgen rdf:about="http://www.example.org/oxgen" />
</m:bonds_to>
</rdf:Description>
</rdf:RDF>
</metadata>
<circle cx='400' cy='170' r='20'/>
<circle cx='400' cy='230' r='20'/>
<circle cx='600' cy='170' r='20'/>
<circle cx='600' cy='230' r='20'/>
<circle cx='500' cy='200' r='100' fill='url(#carbon_fill)'/>
</g>
</svg>

The <metadata> element as a child element is obviously associated with its parent, thus “tagging” it. There is no established method for placing the <metadata> element to best associate collections of elements, but setting it as a child of a <g> (group) element containing all the relevant children seems a likely choice. This allows us to say that circle is a carbon atom, and that line is a molecular bond. On the downside, RDF is a bit verbose, and it isn’t ideal to tag text.

Text content in RDF (or any given XML format) is not visible. This is because SVG dictates that content inside unknown elements (that is, elements not defined in the SVG specification) is not rendered, even if it is also the child of a <text> element.

Microformats

Microformats may be a good option here. While most people associate the class attribute with CSS styling, both the HTML and SVG specifications list one of its roles as “general purpose processing by user agents.” I haven’t seen any microformats user agents (browsers or other programs) that specifically support SVG, but it shouldn’t be hard. The basic syntax and functionality would be the same. Basically, you might say something like <text class=”acronym”>SVG<title>St. Vincent and the Grenadines</title></text>.

A minor problem with this is that SVG Tiny 1.1 doesn’t have the class attribute, but this should work fine with SVG Full, and SVG Tiny 1.2 does include the class attribute specifically for uses other than styling (e.g. micoformats). A potential negative with microformats itself is that since it is such a loose ontology, I’m not sure it will scale up to complex contexts, and I think that it will be subject to the same semantic drift that natural languages suffer (where one word takes on a new meaning, like “decimate”); in fact, since there will be no immediate feedback, as is present in spoken language, I think the drift will be accellerated. This makes for stale semantics down the line, but it will probably suffice for the short term (and who knows how long the content will last anyway?).

XBL2

Finally, there is a new technology being published by the W3C, one originating with Mozilla, called the eXtensible Binding Language (XBL2). Among other things, it allows an author to create templates that attach a presentation format, like HTML or SVG, to any arbitrary XML. So you could take your Chemical Markup, or Genealogy Markup, or whatever, and create XBL SVG templates for it. Whenever there is a element that matches one of your templates, the appropriate SVG (or whatever) markup is created and tied to the target element, preserving the original semantics while providing an appropriate visualization. Since this is a new technology, the obvious drawback to this approach is that there aren’t yet browsers that support it. Also, it may not be appropriate for mobile devices. But I think this will be the rich option available within the next couple of years.

Conclusions

SVG has inherent accessibility features, and specific built-in geometric semantics. With a little work, semantically rich documents and applications can be built using SVG in combination with the appropriate ontology and a semantic tagging mechanism.