Geometric Accessibility Who needs SVG?

Recent experiments with certain types of SVG graphics have several implications for accessibility, including, perhaps, a broadening of the concept of accessibility within the graphical environment that is SVG. Two primary use cases are examined in some detail:

Among the topics to be discussed are:
  • Presentation versus semantics . in SVG what parts are merely presentation?

  • What does the spec currently say?

  • What do browsers and authoring tools currently do?

  • Accessibility to those with visual impairments

  • Possible futures: tactile accessibility, accessibility to search engines, script, and development teams.

The author will make the point that the boundary between semantics and presentation is considerably fuzzier when the expressive metaphor for web pages is spatial and graphical (SVG) than when it is textual (HTML). The implications for a) what the spec should say about accessibility b) how authoring tools should assist and c) how authors conceptualize their expressions will all bear careful scrutiny in the upcoming years as the .web. seeks to embrace so many different models of communication. The notion that text and HTML are somehow fundamental in this planning process is strongly questioned.

Table of Contents

Introduction
Background
Examples of text departing from standard alignment
Case studies . what sometimes goes wrong with SVG and text.
Problems caused by SVG limitations
Wrap-up
Bibliography

Introduction


At first glance it is simple. The “T” in HTML is for text; the “G” in SVG is for graphics. We have two distinct worlds.

But then we can look at the real world of shop signs, corporate logos, CD and album covers, packaging, and labels and we find that the artists of the real world have blurred the line between text and graphics in fascinating ways.  In the Arab world, as in the world of Chinese calligraphy writing and art, semantics and geometry become juxtaposed, fused and counter-pointed in ways numerous and hard to categorize.

In this paper we are interested in exploring the relationship between the characters of text and the geometry of their presentation. We’re also interested in discussing how that relationship can affect accessibility in various ways and for various audiences. We’re also interested in identifying some of the ways that SVG as a standard, and that SVG authors as practitioners might improve accessibility for graphically rich text. Ultimately, we’re interested in raising (or perhaps re-raising) the issue of what is the difference between presentation and semantics when it comes to graphics.

As the popularity of incorporating SVG graphics on web page increases, so do the implications for accessibility especially if a broadened definition of accessibility is employed. Our broadened definition of accessibility within the graphical environment includes the visually impaired and the blind, but is expanded to also include the human reader of code and future search engines. Often times, SVG is read and modified by the human coder and thus needs to be readable. This type of readability is analogous to the concept of self documenting code that is encouraged (and oft required by organizations) of programmers creating desktop applications.  The expansion of the accessibility definition to include search engines is a result of recognizing the fact that future search engines may display or index SVG. Consider search engines of the future looking for examples of pentagons found in North African tilings rendered in SVG.  Current HTML-oriented search engines can find the words pentagon, pentagonal, Pentagoni, البنتاغون, պնտագոն, beşbucaq, pentagono, пяцікутніка, পঁচভুজ , петоъгълник and even recognize similarities in their meaning. Might it be unrealistic to think that SVG-aware search engines might one day be able to find and "understand" the similarities between the rollowing geometric instantions of pentagons? We think not, but we think it may be time to begin to envision such a day.

five-sided purple pentagon Magenta pentagon Magenta six pointed pentagon Magenta six pointed pentagon
SVG path (five points) -- a convex pentagon
<path fill = "#771fab"
d="M 257 189 188 285 77 248 77 131 188 94 z"
stroke = "black" stroke-width = "1" />
SVG path (five points) -- a convex pentagon
<path fill = "#f83379" stroke = "black"
d="M 32 55 111 41 157 106 120 145 25 98 z"
stroke-width="3"  />
SVG:polygon: Six coordinates; first two redundant
<polygon fill = "#f83379" stroke = "black"
points="32 55 32 55 111 41 157 106 120 145 25 98" 
stroke-width="3"  />
<clipPath id="C"><path
d="M 32 55 111 41 157 106 120 145 25 98 z"  />
</clipPath>
<image xlink:href="p17.jpg" width="180"
clip-path="url(#C)" height="170" />

Background

Obviously, desc and text tags can be used by programmers to address the problem.  However, programmers are notoriously lazy and do not often use these descriptions.  In the United States, the nondiscrimination requirements in Title II of the Americans with Disabilities Act (ADA) applies to state and local government websites. The toolkit [REF1] specifically mentions HTML tags, but does not yet mention SVG tags.

Currently, websites often rely on graphics to convey meanings:  many companies now draw their logos (e.g., HTML5 logo),  graphics for often used symbols (e.g., copyright symbol and non-copyright symbol, text is drawn (word art), an textual effects of a visual nature (word art, word puns,  calligrams, shape poems). When graphics are relied on, a visually impaired person may miss the semantics of the page.

Content accessibility guidelines do exist for SVG [REF2]. The content accessibility guidelines according to the W3C recommendation include: provide text equivalents for graphics, do not rely on color alone, use markup and styles sheets properly, clarify natural language usage, and ensure that dynamic content is accessible.  In addition, the W3C recommendations include authoring tool accessibility guidelines and user agent accessibility guidelines.

What SVG can do currently with text:  theory and practice

The SVG 1.1 specification for text [REF3] is approximately 90 pages long (if printed). SVG provides the ability to vary these properties of text:
Support for these features is not uniform across browsers . There are, indeed, discussions afoot suggesting SVG font support be replaced with the weaker server-side downloadable technology of WOFF.

Additionally, through others of SVG’s features (like masks, clip-paths, filters, gradients, transforms, animation, replication, pattern, and script) , we have the ability to
What is currently lacking in SVG1.1 (without extensive scripting or server-side intervention) are the following:
We will argue that all of the above features are a part of the extant world (both the physical and web-based world) and that for reasons of accessibility (as broadly interpreted) they are useful additions to SVG. In particular there is need for such effect and SVG is the place where most logically they belong

Examples of text departing from standard alignment:

How do people use text in “the wild?”

In beginning work on this subject we sought to gather examples of real world uses of text. We not only kept a lookout for such things as shape distortions and varied geometries, but did some Internet searching for special text effects.

A wide variety of interesting effects were found. (Many can be seen at http://srufaculty.sru.edu/david.dailey/svg/top-align.htm  )

In this section we will present some "found examples" of natural text

Top alignment

SVG has long recognized that text flow (directionality) as well as alignment vary as a function of language. The SVG spec mentions specifically the Indic scripts as varying baseline alignment:
Top-aligned Bangla script
Example from http://crblpocr.blogspot.com/2008/07/how-to-test-bangla-and-devanagari.html .

However one need not go to India nor Bangladesh to find examples of varied alignment as the following examples demonstrate.
Rush album cover Blue Ribbon tavern, western PA

Book cover from: http://www.glogster.com/media/4/14/98/42/14984230.jpg
see also http://www.rangersapprentice.com/
Rush album cover from:
http://www.canadiandesignresource.ca/officialgallery/
wp-content/uploads/2008/07/rush1974.jpg
Shop sign (western PA), from:
http://c2.ac-images.myspacecdn.com/images02/
87/m_fe64ca0fef8b45dab7c29db8e31eec89.jpg

If one actually looks for top-aligned English text, it is in fact fairly common.  But this is not an easy effect to accomplish in SVG, even with script. See for example the discussion in the public archives of the SVG Working Group (at http://lists.w3.org/Archives/Public/www-svg/2011Jun/0006.html )

Experiments with making top-aligned text using SVG and JavaScript may be seen at http://granite.sru.edu/~ddailey/svg/tspanmeasure.svg and http://granite.sru.edu/~ddailey/svg/tspanmeasure4.svg

The last attempt is actually successful in Opera, but here are the results of trying to top-align text in different browsers:

results of top alignment attempts, across browsers

Figure 1: http://srufaculty.sru.edu/david.dailey/svg/TopAlignBrowsers.png


Dual curve alignment

In the authors' search for examples in-the-wild of top-aligned text, we found, somewhat to our surprise, that "dual alignment" in which text is aligned simultaneously to be a top and bottom curve is actually more common still. It is a far more common typographical effect than we would have predicted at the beginning of our analysis of such things. Herewith are just some of the many examples:

NFL logo -- various 
depictions HTML5 logo Harley Davidson logo
Google image search for NFL logo HTML 5 logo:
http://www.w3.org/html/logo/
Google image search for Harley-Davidson logo d
Rubber Soul album 
cover Beatles Album cover -- 
Tijuana Brass 3D text Photoshop 
effect
Google image search: Rubber Soul Album cover -- Herb Alpert's Tijuana Brass Photoshop effect from
http://www.photoshopfiles.com/photoshop/
text_effects/3d_text_effects__499.html
fObey Stereo -- clothing and 
skateboards Logo for Cooler Master company Text effect 
Silverlight
From http://obeyclothing.com/blog/?p=1875 Cooler Master logo:
http://www.coolermaster-usa.com/
Text effect:
http://wsmithdesign.wordpress.com/
2010/05/26/silverlight-text-effects/

It is noteworthy that a) the glyphs themselves (and not merely their baselines and font-sizes) conform to the top and bottom curves and b) that these effects are not linear. That is to say the warping of the glyphs is often curvilinear and can not be produced merely by applying a perspective transform to the text.


Shape art: including word poems

Results of a Google image search for "shape poems", as shown below indicate that shape poems tend to be either designed to follow a path (currently possible in SVG) or to flow into a shape. Though the "rules" for how to flow text into complex shapes can be nontrivial, and probably are non-algorithmic, instead relying on the author's sense of  semantics, legibility and good design.
Google image search 
results for "shape poem"

In the following examples, it is clear that even with SVG's current text-on-a-path and the proposed text-flow-into-a-shape, the curvilinearity of glyph reshaping can be quite complex at times.

deviantart, typography by fuzzyzebra biang-biang-mian
From http://www.designflavr.com/resources/
21-Inspirational-Typography-Artworks--from-DeviantArt-i116/
From http://www.hiddengarments.cn/index.php/tag/zhaoqing/page/4/




Glyph Distortion

http://wwwdelivery.superstock.com/WI/223/1850/PreviewComp/SuperStock_1850-23262.jpg http://arro-signs.co.uk/3d-letters/wp-content/uploads/2010/10/pictogram.jpg
Source: http://www.superstock.com/stock-photos-images/1850-23262 Source: http://arro-signs.co.uk/3d-letters/chinese-writing/

Glyph decoration:

Wallmonkeys Peel and Stick Wall Graphic - 
Flower Chinese Word "hei" for Chinese Wedding

Source: http://www.amazon.com/Wallmonkeys-Peel-Stick-Wall-Graphic/dp/B005IVQS98/ref=sr_1_23?s=baby-products&ie=UTF8&qid=1317522255&sr=1-23

Typographic Puns (double doubles)

The term "visual pun" often refers to things like this picture of a huge manatee (zepelin shaped) crashing into a tower with the caption "Oh the huge manatee!" Unlike the word poems,
for example, this from http://dbqp.blogspot.com/2007/03/this-is-your-body-this-is-your-blood.html :
Egg shape filled with egg 
text
these "typographic puns" tend to draw the concept of the word using exactly the letters of the word (no extras),  with a bit of orthographic styling.  The older reader may remember a semi-regular column in Playboy Magazine consisting of a page of typesetting puns.Here are several I remember from my youth:

Protect with protective 
TPimento with pimento inside O
Censored with blacked out 
letterTomato with tomato slice for OElevate with elevated E
All but "PROTECT"  viewed at http://granite.sru.edu/~ddailey/svg/embedpun.html in Opera. proTect as viewed in Internet Explorer with Adobe plugin.


Here are some others of the same general ilk that I was able to find on the 'net and that illustrate the very same concept:

swarm made of a swarm
From Adam Paxman at http://adampaxman.blogspot.com/2009/08/typographic-pun-fun.html

 
ECLIPSE
From http://jonahschrogin.blogspot.com/

Addding subtrcting 
multmultiplying div id ing
From http://jamesbrook.wordpress.com/2011/01/10/watching-words-move/

One of the points to be made from these sorts of examples, is that while the typographic effects are relatively easily brought about if the author is willing to hand-adjust the placement of the special effects (the mask in "ECLIPSE", the Tomato, or the rectangle in Censored) the current mechanisms available for performing many of these operations in script is virtually non-existent in SVG. Some browsers use getBBox, while others prefer getExtentOfChar. None seems to have implemented these things completely consistently with the spec. Furthermore, the ability to rescale the T in PROTECT is present only in the Adobe plugin and is apparently inconsistent with the spec on this matter. <tspan> tags within a <text> have very little control over positioning, other than the obvious tags and are not full partners in the SVG pantheon of tags. Applying transforms to stretch the font does not work except in IE/ASV and the ability to stretch parts of the font and not other will not become possible unless SVG exposes font-geometry to authors in some way.

More importantly for accessibility, without SVG fonts to allow the final O in tomato, or the obscuring rectangle in Censored to be viewed as glyphs, there is no way for a screen reader to determine what the word censored or tomato are unless the author overtly provides those accessibility cues manually -- something authors are notoriously negligent at doing!

Calligrams (extreme glyph distorition)

Calligrams are drawings made of glyphs. Here are some examples from Chinese, Arabic and English.

beautiful girl calligrambeautiful hometown calligramCrab calligram
Copyrighted calligrams (linked in-line here) from http://www.flickr.com/photos/24235169@N04/with/4754291334/  (see also http://www.chinasmack.com/2010/pictures/chinese-character-art.html )

bicycle calligram from 
Beijing International Design Triennial
By Hua Jiang for the Beijing International Design Triennial. Source: http://en.bidt.org/designer/413.html


Cylindrical text from Israel Eisenberg
http://owl3d.com/tests/cylinder_text.svg

Text effects in the wild: an inventory.

The above examples (in various categories) all represent experiments with the geometry of text: either with the shape of the glyphs or their alignment relative to one another or both. It is natural to wonder how commonplace are these sorts of effects in behavior of designers, web authors, merchants, and typographers. Accordingly, we performed a quick inventory of textual effects by performing a search in Google Images for "font effects" and "text effects." About two hundred images were examined and about one hundred were selected for closer examination (about half were totally uninteresting, because of duplication, irrelevance, or illegibility.) The following shows some of the images and an intermediate stage in the process of classifying these effects.

text effects -- examples 
in the wild
Generally, it was observed that the predominant categories of "found objects" were
The good news for SVG is that most of the standard text and font effects that web authors tend to utilize (almost always through bitmapped images) are relatively easy to accomplish within SVG at present. In the following section is a collection of examples of many of the currently supported effects that can be applied to text in SVG. The more complex shape distortions such as discussed above seem to appear more in the world outside the web, perhaps since few design tools currently support them.

Text effects that are possible and currently supported in SVG

As illustrated above in Figure 1, browser support for text effects is not uniform. In fact as the author of one and a half books on SVG, one of this articles authors can claim that of the major components of SVG (including paths, masks, filters, patterns, animation, and text), text has the least consistency of cross-browser support of any of the other parts of the language. As such, some of the effects shown work only in some browsers. The most consistent and broad ranging support can be seen currently with the Opera browser, and as such, the reader may wish to use that browser for viewing some of these examples.

Here is an example (visible at http://srufaculty.sru.edu/david.dailey/svg/text/textplay.svg ) in which browser support is markedly inconsistent:

Another involving vertical alignment (at http://srufaculty.sru.edu/david.dailey/svg/text/verticalText.svg ) shows similar cross browser problems.

Filling text with gradients or patterns (not clipPaths)

It is quite easy using <text  fill="url(#pattern)" ... > or <text  fill="url(#gradient)" ... > to fill text with either a pattern or a gradient. Here is one simple example of each.
The words "rainbow colors" filled with rainbow colored 
gradientThe word "flowers" filled with floral pattern
Text filled with a gradient
(See http://cs.sru.edu/~ddailey/svg/rainbow0.svg   )
Text filled with a pattern
( see: http://granite.sru.edu/~ddailey/svg/flowers0.svg  )

See also

One thing that SVG can do with such effects that is not so easy to do with bitmapped formats (such as jpg, png, gif, and <canvas>) is to animate these effects by adding a simple lines of declarative code. Here are three examples that illustrate the terseness and simplicity of SVG animation:
Animated effects using gradients or patterns
One very important  thing that should be said about these effects in SVG is that the text remains text.
This is not true when we use text within a clipPath to carve a path into an image. It is better, for accessibiity purposes,  to fill text with a pattern containing an image than to carve the image in the shape of the text. Compare these two examples:

Letters of "Belize" filled with picture of Belize 
(copyrighted 2011 by David Dailey)Picture of Belize, clipped by 
letters of Belize
Text filled with <pattern> containing <image>
( See http://srufaculty.sru.edu/david.dailey/svg/text/belize.svg )
Image carved by clipPath containing text
(see http://srufaculty.sru.edu/david.dailey/svg/text/belize2.svg )

An additional advantage, as shown, is that the text can further be styled (as by a stroke) which is not true when the text remains inside a clipPath.

Drop shadow and reflections

http://srufaculty.sru.edu/david.dailey/svg/text/Pizza1.svg
http://srufaculty.sru.edu/david.dailey/svg/text/colorful3.svg
http://srufaculty.sru.edu/david.dailey/svg/text/colorful4.svg
http://srufaculty.sru.edu/david.dailey/svg/text/offsetblur2.svg
http://srufaculty.sru.edu/david.dailey/svg/text/reflection1.svg

Texture

http://srufaculty.sru.edu/david.dailey/svg/text/burst2.svg
http://srufaculty.sru.edu/david.dailey/svg/text/chrome1.svg
http://srufaculty.sru.edu/david.dailey/svg/text/chrome3.svg
http://srufaculty.sru.edu/david.dailey/svg/text/chrome4.svg
http://srufaculty.sru.edu/david.dailey/svg/text/chrome5.svg
http://srufaculty.sru.edu/david.dailey/svg/text/decorative.svg
http://srufaculty.sru.edu/david.dailey/svg/text/porcupine.svg
http://srufaculty.sru.edu/david.dailey/svg/text/offsetblur6.svg
http://srufaculty.sru.edu/david.dailey/svg/text/ripples2.svg



Distortions and warping


http://srufaculty.sru.edu/david.dailey/svg/text/crinkles1.svg
http://srufaculty.sru.edu/david.dailey/svg/text/wavy1.svg
http://srufaculty.sru.edu/david.dailey/svg/text/ripples5.svg
http://srufaculty.sru.edu/david.dailey/svg/text/ripples6.svg
http://cs.sru.edu/~ddailey/svg/zebra1.svg

3D Effects


http://srufaculty.sru.edu/david.dailey/svg/text/offsetblur4.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic2.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic3.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic4.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic5.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic7.svg
http://srufaculty.sru.edu/david.dailey/svg/text/plastic8.svg
http://srufaculty.sru.edu/david.dailey/svg/text/rainbow.svg




Animation

http://srufaculty.sru.edu/david.dailey/svg/text/wavy2.svg
http://srufaculty.sru.edu/david.dailey/svg/text/ripples10.svg
http://srufaculty.sru.edu/david.dailey/svg/text/ripples11.svg
http://srufaculty.sru.edu/david.dailey/svg/text/fire7.svg
http://srufaculty.sru.edu/david.dailey/svg/text/fire8.svg
http://srufaculty.sru.edu/david.dailey/svg/text/bubbles8.svg
http://srufaculty.sru.edu/david.dailey/svg/text/bubblesc.svg
http://srufaculty.sru.edu/david.dailey/svg/text/chrome6.svg
several of these effects can be seen at once at http://srufaculty.sru.edu/david.dailey/svg/text/texteffects2.htm

Case studies – what sometimes goes wrong with SVG and text.

Paste in my email to Chaals about the HTML5, and also the case study on uncopyrighted.
Sample of using pictures to convey meanings

[1] The topic borders on some fairly fundamental issues of SVG semantics, I think: in geometry, how to separate presentation from semantics? Consider the two halves of the pseudo-glyph 5 in the HTML5 logo. The semantics *is* a 5, but what form of presentation language would style it into four differently colored paths? That would require, I think, a more powerful theory of presentation than the fun thing known as CSS was intended to be. Separating the x,y coordinates from everything else, would be an obvious course of action, but then what of feDisplacement or transform which serve as modifiers. If we are to extend so that (by extension from ) will be able to go and morph the modifiers of objects: the gradients, the filters, the transforms, the patterns, and the masks , then thinking of geometry as somehow distinguishable from presentation seems to me to be of limited utility. Texture is just as tactile as shape if we render our shapes in another modality. [2] some attributes cannot be d Hi guys, here are a few reactions as well as a few other versions.

First: Chaals, I'm perfectly happy with what you've done here. It addresses the primary concerns I had of accessibility and also cleans out the majority of the silliness. Labeling the shapes H, T,. M and L with a title on their superordinate group and then giving each an id makes sense. Maybe giving each shape its own title would make more sense, but as Doug pointed out to me in a separate e-mail a month or so ago, we don't quite know yet what search engines are going to ultimately index inside an SVG, and screen reader technology may not advise us here. I guess I'd say titles would be better than id's, though Doug also points out that there are new SVG accessibility guidelines in preparation somewhere.

Third: There are some issues here which I think go deeper than just what should the HTML5 logo look like, and how should it be marked up: things that I think might deserve a broader discussion, though perhaps about a topic less meaty than an icon meant to represent a W3C trademark of sorts (though there may be interesting intellectual property issues surrounding an icon that W3C encourages experimentation with!). I've said enough about this particular image and my reaction to it and don't really want to rehash any of that. The problem at hand is given a shape that represents some meaning that involves meaningful, alphabetic characters, how best to render that appearance in SVG given an infinite number of ways that superficial are bitwise identical? There are many aspects of the underlying code associated with a shape that might ultimately affect accessibility, depending on the audience we might wish to reach. I can imagine, for example, a screen reader which might attempt to convey aspects of the geometry of a shape to someone. In this context a square drawn as a rect, a path, a polygon or a square unicode character might all look the same, but have different underlying "meaning" in the sense of geometric reasoning.

Fourth: In your drawing, Chaals, I note a couple of things that you didn't change from the original that I might. a) I don't think we need even this many digits of accuracy. If the accuracy were real I might disagree, but in fact it was drawn by hand and some of the coordinates are in fact inconsistent:

a1) in the and second polygons we find the coordinates: 255.778,512 and 256,480.523. In truth, the first should really be 256,512, since the two vertices are supposed to align vertically to preserve the symmetry of the illustration. That 2/9ths of a pixel is really an error from the artist, I think! I recommend rounding to the nearst half pixel. (as is done in version 2 of the attached logos) to *enhance* accuracy and reduce file size. a2) Often times, if we do round to the nearest half-pixel, we find duplicated adjacent pixels: for example in the first subpath of the "5" we have 256,176.305 followed directly by 255.843,176.305 -- I think this was a bit of hand-tremor or else an Illustrator artifact. a3) there are a lot of nearly or exactly collinear points along the polygon. Why include a series of collinear points? I suppose if we wanted to reflect the fact that the artist waivered while drawing the shape, for subsequent animation of the history of the artist's activity, that could be handy, but I don't think W3C is interested in glorfying the artist's deliberations here, interesting though they may be! a4) It makes more sense to organize the sub-polygons of the "5" in an order that represents their drawing sequence. If you give each a different color you can see they are presented in the order upperleft, lowerleft, lowerright, upperright, rather than a stroking order which would be upperright, upperleft, lowerright, lowerleft. Trying to "feel" these shape would be easier if it were rendered in an order matching its shape as stroked

b) Combining the four polygons into one really makes more sense semantically to me. Version 2 of the logo does this with a gradient applied from left to right. The colors should be identical to that in the logo provided, but now it is one shape that has a different fill on its left half than on its right half. It just makes more sense. I might be tempted to add a that explains that this polygon is meant to approximate the shape of a 5, so that one might understand that similarity is perceived between the shape and the curvilinear glyph.

I think this version is a modest improvement over yours which is a large improvement over the first. It's quite a few hundred less characters, for one thing, an improvement to the geometry (I think, since verticle is really verticle now along the midline), and a lot fewer extraneous points.

Fifth (moving on to version 3): If we try to reverse engineer the artist's intention, I think the lighter color on the right half is of the 5 meant to harmonize with the lighter color of the right half of the shield. That is it is as though a brighter light is hitting the right half, or as though the shape has been bent in three space. To do this, and preserve exact color values one would need a filter I think, since I think neither opacity (which I've used) nor a mask will do what we want. But, version 3 is "similar" in appearance and, arguably, more accurate in semantic intent. Using filters though would not work across all browsers (clearly a show stopper), so I've not tried. The advantage to overlaying a semi-transparent shape over both, is that if the W3C wished to calibrate (as you seem to indicate) the colors of the left with the right, I think this would be an easier way, perhaps to yoke the two. Not completely sure, and could see myself being persuaded otherwise.

Sixth (version 4). Is there really no way to get fonts to display consistently across browsers? In version 4 I came pretty close using style="font-family: Arial Black, sans-serif" kerning="3" font-weight="bold" font-size="96px" and it looks pretty good in Opera, FF, Chrome. (Not in IE+ASV and I can't see IE9). I've overlayed the text in transparent red atop the black polygons so the differences can be seen. Clearly the M in HTML is different than any standard fonts I could find. So we may be stuck with polygons. On the other hand wouldn't it make more sense (in the grand scheme of accessibility) to draw the paths as glyphs within a font and then use the font inside a text tag. Then we would *know* what the shapes of the glyphs HTML are supposed to render. Where is this discussion with WOFF versus SVG fonts? every one I have heard speak to the issue says that SVG fonts are infinitely preferrable. It would seem that from the accessibility point-of-view this is absolutely true, or am I missing something?

Perhaps getting Jeff Schiller's (and my) interest in having the coordinates of fonts exposed as paths to the programmer from within SVG is a logical compromise if the other browsers aren't intererested in doing real typography. I think that that will be a big mistake to lose SVG fonts!

Anyhow, I'll be interested in your reactions to any of this rather lengthy message.

b) A fellow from the standards community approached me recently with questions about how to simplify the HTML5 logo that was discussed here recently in one of the forums. In looking at the code there were several issues that did not make sense semantically, and those had been introduced because of the use of the Illustrator tool: things like . Listing the same coordinate twice is rather silly. Things like points="100.20712336,50.8720913 400.000232,200.1345982 ..." : do we really need that level of precision in something that was sketched by a human hand with all its muscular and neurological flutters? , things like "1,2 2,3 3,4" : the insertion of collinear points along a path generally has no "meaning" ; irrelevant namespaces introduced by the tool. Jeff Schiller's tool for removing the "cruft" helps with some, but not all of this. If we really do mean a quadrilateral, then should the underlying code not have four points? I think a part of the discussion we've been having on that issue may become public and I'll hope to let you all know about it when it does since there are a lot of complicated considerations. I think I mentioned something about my somewhat quixotic dealings with the SVG code underlying the Wikimedia Commons symbols for copyright and public domain -- if anyone is interested I can try to find a reference.

c) I imagine search engines in the future that might want to find examples of pentagons found in North African tilings rendered in SVG. How possibly might we do that if the code has been encrufted with semantic irregularities? On the other hand, the issue of how accessibility tools of the future and search engines of the future might either display or index our SVG is a complicated issue and one that is intriguing to ponder.

I'd be interested in seeing your thoughts on the image at http://commons.wikimedia.org/wiki/File:PD-icon.svg

Which of these: http://granite.sru.edu/~ddailey/svg/pd4.svg is better, in terms of accessibility versus appearance?

The first has four circles and three rectangles. The second has one circle, one line and the letter "c" (which is more "as we view it"). The problem with the second is that despite it making some good sense semantically, it may render differently in different browsers. All five environments I have show it almost identically!

Let me know of your thoughts on the subject as I am not sure of whether it is worth suggesting the replacement of the file at Wikimedia.

Tonight I will try to remember to let you know of a sort of fun script I wrote over the weekend. It takes images of the sort found at http://openclipart.org/ or even Wikimedia Commons and allows one to inspect the pieces of an object so that you might find where in the code the actual object appears. See the thread on repositories of svg images started by Patrick Maslen here for background.

I was reminded of how much irrelevancy is embedded in the typical image output from Inkscape: . sodipodi namespaces everywhere . gradients and even filters that are defined but never used . far more decimal precision that is needed . etc. Jeff Schiller's program called Scour is perhaps what I should have used.

Here's another example that I did replace at Wikimedia. I took the original from 5kb down to 895 bytes, and made the semantics of the paths a lot closer to what is really meant than the rather lengthy series of bezier cubics used to make a similar shape.

I guess my disagreement with the existing thing in Wikipedia has several components: the use of two circles to describe one is semantically inaccurate; the use of a matrix transform on a rectangle to describe what is more semantically a slash (or perhaps a line). Rotation about the center of the circle is really what is happening rather than a matrix transform. And I'd have to disagree about the semantics of the "c" not meaning copyright. The copyright symbol originated, I believe, in US law and is defined there as a c within a circle (See US Code TItle 17 section 401) . I don't think that section of the code has changed in the past 100 years though the required use of the symbol was dropped in the US when the Berne treaty was adopted. The symbol in frequent use in Wikipedia, however, has come to emphasize the interplay between the shape of the circle and the shape of the glyph inside it. Interestingly, when the Unicode version of the copyright symbol is set in a serif font, the close geometric interplay between the circle and the c is lost. Running a slash through a font that may appear in unpredictable locations is likely to cause visual confusion, since relevant visual cues may be occluded by the slash. Do we want our symbol to be able to inherit stylistic attributes of the surrounding text (like serifs, italics and font-weight)?

I think that I would probably be happiest if one were to define a glyph (SVG allows us to do that) corresponding to and used for © and then use a properly defined geometry rather like what the Wikimedia symbols has done. There is still the nagging issue that the outermost circle means two things: part of the copyright symbol and part of the negation.

The font-designers I know advocate building separate italics and boldface versions of each glyph rather than relying on the browsers font-layout engine to apply its slant algorithms to a given glyph to produce italics, but I don't know how hand-made glyphs respond to font-styles since so few browsers actually support SVG fonts yet. (Only IE+ASV does it completely, though Opera handles paths). Clearly if the symbol is only geometry then it would be unaffected by the surround. It seems as though the Wikimedia symbol is being thought of as a symbol for visual works rather than as a mark of attribution (like copyright) that would have accompanying text: like copyright 2010 by so-and-so. What the equivalent utterance for PD works would be is slightly unclear to me: uncopyrighted 2010 by so-and-so?? In one of my many digressions on copyright law, I talk about inheritable uncopyrightability as in gnu licenses, and it seems like the mark in use in Wikimedia bears possible ambiguities of meaning simply "not copyrighted" or, more strongly: "never to be used as part of a copyrighted work". Hence the flirtation with the semantics of "don't" borrowed from the use of the circle with a line through it!

Problems caused by SVG limitations

Often times, graphics are used to make text appear exciting or flashy creating accessibility issues for the viewer. In such instances the path tag is employed by both SVG generators and human authors  instead of the text tag since the text tag is quite limiting.  Even if the author drew the graphics with geometric shapes, the problem still exists: to the human reader and the automated screen reader, the SVG code is unintelligible.

Another problem that often occurs in SVG code is the use of decimal values.  The geometric values of x and y coordinates could appear as (98.734, 30.123002) and a second point in the path could be (27.63, 30.123). Did the author mean to make a vertical line or not? At what magnification level would the line no longer be straight? Magnification is a necessary tool for the visually impaired.  In addition, at what decimal precision does round-off take place when transformations are applied to the paths or geometric shapes.

Sophisticated screen reading software for processing svg to describe the graphics specified by the code could be developed.  The developer would need to modify coordinates used by some svg programmers when decimal places are used. For example the x, y pairs (3.0, 5.112001) and (12, 5.112) would appear as a line on a monitor, however, the software developer would need to modify the y coordinate in order to determine that the pair of points is a horizontal line.

Current svg specs
-    Where are the specs currently and what is underway. [XXrun this part by Doug Schepers]

The SVG 1.1 specification for text [REF3] does not mandate the use of the desc, title, and text tags
The transformations in the svg specifications describe the matrix operations at a detailed enough level so that the various svg interpreters (opera, firefox, and IE) all perform the operations similarly, but not identically.

Experimentation on Firefox 6.0, Opera 11.5, and IE 9 was performed to determine how each browser handled transformations.  For each browser, a simple rectangle was rotated 50 times at 45 degrees and the coordinates of its BBox were tracked.  Firefox use 8 places of precision, whereas Opera and IE each use 14 decimal places. Of the three browsers, firefox is the most internally stable; after a complete 360 degree rotation(8 transformations at 45 degrees), all 8 decimal places are the same.  Curiously, Opera and IE (both using 14 decimal places) require two complete rotations (720 degrees) before their 14 decimal places are the same as 0 degrees.
The table beloww shows the x values for a complete rotation of a recatangle:

Degrees Firefox 6.0 Opera 11.5 IE 9
0' 197.02343750 197.02305603027344 197.0230712890625
45' 224.94921875 224.9499969482422 224.9499969482422
90' 196.81250000 196.81089782714844 196.81092834472656
135' 199.80078125 199.79998779296875 199.8000030517578
180' 196.80859375 196.8109130859375 196.8109130859375
225' 224.94921875 224.95001220703125 224.94998168945312
270' 197.02343750 197.0230712890625 197.02305603027344
315' 200.10156250 200.10000610351562 200.10000610351562
360' 197.02343750 197.0231170654297 197.0230712890625

 When examining IE and Opera’s values, if only four decimal places are used, then 0 degrees is the same as 360 and 720 degrees (and for all 8 intermediate rotations). Moreover, when looking across browsers, the four decimal places for the first 23 rotations for both IE and Opera are identical. 

At three decimal places, IE and Opera are identical for all 50 rotations . However, they differ from firefox in the 3rd decimal place. All three browser with 2 decimal places of significance are stable and identical.


Wrap-up

Although it is advised that SVG programmers thoroughly document their code for accessibility purposes by using desc and title tags, the use of these tags is not enforceable. Tools that generate SVG could prompt the user for the appropriate accessibility data and generate tags automatically.

-    SVG modifiers for text effects – vector effects, replicate, warping to shape, shape wrapping, etc.

SVG should provide a glyphToPath() method that exposes glyph geometry
getExtentOfChar should provide a bounding box of each glyph separately rather than as implemented in most browsers.
be given full status: namely the ability to apply transforms, clipPaths, filters, etc.
text within clipPaths as applied to other content be selectable

Also it is suggested that svg authors limit the number of decimal places they use when creating x,y values to two decimal places. Two decimal places permit a magnification of 100 before the svg object could appear differently.  Given current screen hardware resolution, two decimal places is reasonable. Of course, interpreters could get remove unnecessary decimal places (or some level of precision keyed by viewBox).

The differences in browsers as demonstrated by the experimentation, leaves the authors with the conclusion that browsers do differ and that browser interoperability needs to be further explored and possibly the SVG specifications will need to be revised.

[REF2] SVG Content accessibility guidelines. http://www.w3.org/TR/SVG/access.html#SVGAccessibilityGuidelines

[REF3] SVG 1.1 specification for text. http://www.w3.org/TR/SVG/text.html