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:
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.
|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"
|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"
d="M 32 55 111 41 157 106 120 145 25 98 z" />
<image xlink:href="p17.jpg" width="180"
clip-path="url(#C)" height="170" />
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), and textual effects of a visual nature abound (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.
Book cover from: http://www.glogster.com/media/4/14/98/42/14984230.jpg
see also http://www.rangersapprentice.com/
|Rush album cover from:
|Shop sign (western PA), from:
|Google image search for NFL logo||HTML 5 logo:
|Google image search for Harley-Davidson logo||d|
|Google image search: Rubber Soul||Album cover -- Herb Alpert's Tijuana Brass||Photoshop effect from
|From http://obeyclothing.com/blog/?p=1875||Cooler Master logo:
|Source: http://www.superstock.com/stock-photos-images/1850-23262||Source: http://arro-signs.co.uk/3d-letters/chinese-writing/|
|From Adam Paxman at
|Calligraphy of the "Basmala" phrase
bismi-llāhi ar-raħmāni ar-raħīmi
بسم الله الرحمن الرحيم in in the form of a pear.
From http://en.wikipedia.org/wiki/Calligram .
|18th century mirror writing in Ottoman
calligraphy. Depicts the phrase
'In the name of God, Most Merciful, Most Gracious'
with further explanation at http://en.wikipedia.org/wiki/Micrography
|Zoomorphic calligram of tiger Sudanese artist Hassan Musa (from http://www.sudanartists.org/2artwork/hassanmusad2.gif via http://laurashefler.net/arthistory2010/?page_id=345 ).|
|Calligram Elephant by Absurdnyka
|Calligram Ant by ~Inky-la-reve
|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 )
|Text filled with <pattern> containing
( 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 )
|On left: the use of a filter stream to produce a
duplicated, blurred and offset copy.
| On right: the use of duplication with
|fancy decoration of font using <replicate>
|Dash array assisted by <replicate>
|Text crinkled by repeated radialGradient and
|http://srufaculty.sru.edu/david.dailey/svg/text/wavy1.svg||Ripples in water: feDisplacement based on feTurbulence
|http://srufaculty.sru.edu/david.dailey/svg/text/ripples6.svg||Stripes are one repeated radial gradient
distored by another
|feBlur together with feColorMatrix
In January 2011, the W3C announced its new logo for HTML5, together with a request for some feedback. The image is provided under a Creative Commons 3 license allowing derivative artwork, as is seemingly encouraged by the W3C logo FAQ.
At the time, I (Dailey) was struck by one thing (other than a certain aesthetic reaction):
I wrote to the HTML5 WG a
reaction centered on the above complaint, but including a few
other points as well:
"H"= <path d="M108.382,0h23.077v22.8h21.11V0h23.078v69.044H152.57v-23.12h-21.11v23.12h-23.077V0z"/>
<polygon fill="#EBEBEB" points="256,268.217 195.91,268.217 ...etc."/>
<polygon fill="#EBEBEB" points="256,386.153 255.801,386.206 ...etc."/>
<polygon fill="#FFFFFF" points="255.843,268.217 255.843,313.627...etc."/>
<polygon fill="#FFFFFF" points="255.843,176.305 255.843,204.509 ...etc."/>
points="256,268.217 195.91,268.217 191.76,221.716 256,221.716 256,176.305 255.843,176.305 ...
We have (256,176.305) followed directly by (255.843,176.305) -- I think this was a bit of the artist's hand-tremor or else an Illustrator artifact. The actual polygon, in the grand scheme of adopting polygons dating back at least to Euclid would classify this shape as a decagon, rather than the octagon that it is perceived as, and I would argue was intended by the artist to be. If we were to search in some future search engines for "SVG examples concave octagons used as logos" this particular shape would never been found. Points that are nearly identical, probably are.
On the issue of the classification of the n-gon as n-gons
or n+k-gons, there is another issue: There are a lot of nearly or
exactly collinear points along the
polygons. Why include a series of collinear and ajacent points in the
drawing of a polygon? 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 most logos would be
glorfying the artist's deliberations here, interesting though they may
be! In the version of the logo at
the top right stroke of the number 5 is drawn as
"M255,94 L255,129 255,150 255,150 392,150 392,150 392,150 393,138 396,109 397,94"
This could more easily be drawn as:
"M255,94 255,150 392,150 397,94z",
a quadrilateral rather than a decagon, by eliminating redundant and collinear points. The inclusion of adjacent collinear points in a path or polygon (such as "1,2 2,3 3,4") should be avoided by authors and the creators of tools for authors, unless those points truly have meaning.Otherwise, they distort the meaning.
It makes more sense to organize the sub-polygons of the
"5" in an
order that represents their drawing sequence. By giving each of the
regions a different fill pattern (below) 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"
the shape of the "5" would be easier if it were rendered in an order
its shape as stroked.
|Current order of appearance of polygons||Improved order of appearance of polygons|
Note how the left half of the shield and the left half of the 5 are both darker than their mirrors on the right. If we try to reverse engineer the artist's intention, the lighter colors on the right side are meant to harmonize. 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, since neither opacity (which I've used) nor a mask will do what we want. But, a suggestion 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. Sometimes the accessibility we wish to provide is to future artists wishing to make derivative work.
(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.
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="512px"
height="512px" viewBox="0 0 512 512">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 512 512">
Now I should point out, for sake of clarity, that the HTML5 logo is not at all unusual in the sorts of accessibility issues it raises. But the questions of accessibility are rather different. It is not a question of which words to use in a alt attribute to describe an image, though that is the easy part of it. It is a question of how we might provide access to the geometry, the styling, the reshaping, and the semantic gist of the image through the markup itself. In fact, most SVG "found" on the web is far less comprehensible from the point of view of recognizing where multiple objects become one, where clip-Paths provide semantics (as when the shape of text is used to clip picture), when line segments are really vertical, n-gons are really n-k-gons, and when differences in hue are actually shadows thrown by an unseen shape (even though the markup suggests otherwise) .
Suppose, for purposes of accessibility, we wished to replace the paths in the HTML5 logo , by actual characters in a font. We not only want the text to be accessible to screen readers but to selection by the cursor, indexing by search agents, and restyling through menus of assistive fonts that address various different accessibility needs (e.g., Braille, TexturePath(future) or the like).
While <desc> and <title> might tell someone what the letters are, they don’t help with most of these purposes.
The two natural solutions would be SVG fonts and WOFF both of which are standards supported to some extent (though only SVG fonts are currently a recommendation I think) by the W3C, but neither of which, yet has univeral support by SVG viewers for both mobile and browser environments.
A WOFF solution (using a WOFF font for the characters of the string "HTML5" can be seen at this location http://cs.sru.edu/~ddailey/svg/HTML5logo5.svg . It renders almost the same as the original W3C version (in all browsers but Safari -- see comparisons of the original and the WOFF version at http://cs.sru.edu/~ddailey/svg/HTML5logo4.svg as seen across browsers at http://cs.sru.edu/~ddailey/svg/HTML5WOFF.png )but is arguably much more accessible. To begin with, its characters can be selected by dragging the mouse over them (in most browsers)
Which of these: http://granite.sru.edu/~ddailey/svg/pd5.svg is better, in terms of accessibility versus appearance?
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 : 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!
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. Discussion and history may be seen at http://commons.wikimedia.org/wiki/File:Publicdomain.svg
The topic borders on some fairly fundamental issues of SVG semantics. In geometry, do we separate presentation from semantics and if so, how? 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 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 to the geometry.
Once we have understood a complex group of paths (through whatever assistive technology is available to help us understand it) , then is a reuse of that group, via a transform, not intrinsically more understandable than recasting all the objects with new sets of coordinates? <use> is a powerful tool for the author who edits by hand. In many drawing programs, though, it is easier to duplicate and re-set coordinates for sake of not having to carry chains of transforms. For the intelligent screen reader, might it not be simpler to say "two copies of the same thing, one reflected about its left edge" than to re-read a second list of coordinates? By the same token, is not a <replicate> intrinsically more understandable than a zillion <uses> differing from one another by infinitessimal amounts on plenitudes of variables? Accessbility, also means, cognitive accessibility and all the more so when visual impairment may be present.
In SVG as we apply modifiers of objects: gradients, filters, transforms, patterns, clip-paths and masks, then thinking of geometry as somehow distinguishable from presentation is of limited utility. Modifiers modify meaning, and in graphics, appearance is meaning. Texture is just as tactile as shape if we render our shapes in another modality and is not, as in HTML, some sort of presentational attribute left to the responsibility of the public relations department on the 23rd floor of the building.
The problem at hand is given markup that represents some semantics involving 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. While a screen reader which might attempt to convey aspects of the geometry of a shape to someone, a square might be drawn as a rect, a path, a polygon or a square unicode character. They might all look the same, but have different underlying "meaning" in the sense of geometric reasoning.
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.
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 below shows the x values for a complete rotation of a recatangle:
|Degrees||Firefox 6.0||Opera 11.5||IE 9|
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.
|Dual curve alignment
(from http://owl3d.com/svg/tests/boundText/2curves.svg )
|Stretching a glyph (animation)
|Curvilinear Typesetting in SVG
The concept of "how best" to write something got me wondering about
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) Likewise, tools that generate SVG should look for hand tremors - points that are nearly identical, probably are.
While the W3C seems to have backpeddaled to some extent (allowing the debate over retracting the SVG fonts recommendation in favor of the weaker WOFF support to reach ) on its support for text within the mobile and web environments, it is clear that support for the Graphico-Textual world must be addressed. It should happen soon before we have another rash of browser wars with some two of (FF, Opera, Apple, Google, and Microsoft) squaring off agains the other three in a bid for domination of the Graphico-Textual world.Overall conclusions include: