My name is Doug Schepers… and I’m an annotator.
You might be an annotator, too. If you think you might be, you should come to our support workshop in San Francisco in April.
My name is Doug Schepers… and I’m an annotator.
You might be an annotator, too. If you think you might be, you should come to our support workshop in San Francisco in April.
SVG has a few metadata features intended specifically for accessibility, and also provides the ability to use real text instead of images for textual content, just like HTML. This combination of text and metadata serves as one of the cornerstones of SVG’s accessibility; there are other features, such as scalability and navigation features, but this post will focus on the descriptive capabilities of SVG.
I was recently looped into a discussion on the @longdesc attribute in HTML which dealt in part with SVG accessibility, a subject I’m fascinated by. The specific debate is whether a @longdesc value should be applied for SVG, or whether SVG’s native accessibility features should be used, or both.
Let me explain @longdesc. For short descriptions of a picture, a few words to a few sentences, you can simply include the text in the <img> element’s @alt attribute. The @longdesc attribute of an <img> element allows a content author to add a URL that leads to a longer text description of the image. You can read more in this excellent article on @longdesc by WebAIM.
SVG provides a different way to provide text descriptions: the <title> and <desc> elements, which can be a child of any graphic or container element in SVG, and which contain text descriptions of the element. The <title> is meant for shortish names, while the <desc> can provide arbitrarily long descriptions; nothing in the SVG spec limits the length of these elements, but choosing the appropriate text is a best practice (as for any prose). These metadata elements can be read out via screenreaders (accessibility technology that speaks the available text aloud), along with the content of the <text>, <tspan>, and <textPath> elements.
Because each SVG shape (or group of shapes) can have its own <title> and <desc>, a certain amount of structure and sequential flow is available to these screen readers. Each text or metadata element is read out in document order. Together, the series of text passages can comprise a complete description of the SVG graphic. Which is kinda cool… self-describing images!
Well, that’s the idea, anyway. Now let’s look at it in practice, and specifically, at authoring SVG accessible content, and support in browsers and screenreaders.
Note:Â though I offer some specific guidance here, this is not really a tutorial; it’s more a background article on the topic, partly from a standardization point of view. I’ll be writing a tutorial aimed at developers and designers soon on WebPlatform.org.
Continue reading “Current State of Authoring Accessible SVG”
I’ve long been an advocate of wrapping (or “flowing†or “multi-lineâ€) text in SVG. This is basic functionality, and people have been asking for it since SVG started.
I’m also an advocate for moving features out of SVG and into CSS, like gradients, animation, compositing, filters, and so on; the benefits of a single code base for HTML and SVG applications, and ease of learning and maintenance, are obvious.
So, I was excited when the CSS WG took up work to allow wrapping text to arbitrary shapes, like circles or stars, not just boxes. This will enable a whole new magazine-style layout that will benefit web sites and ebooks alike. But I was disappointed when I found out that this work had some recent setbacks and delays.
So, I’m calling for a simple solution now, while we wait for the more complete solution later. And the nice thing is, my solution also relies on CSS!
Several times recently, people have asked on IRC how they can use nice fonts with SVG. My answer in the long-ago past, when Adobe’s excellent SVG Viewer plugin roamed the Earth, was to use SVG Fonts directly embedded in the SVG file… but that’s no longer practical with the current varied browser support.
By far the easiest way to do this today is to use webfonts, such as WOFF.
Authoring tools, like Inkscape and Adobe Illustrator, should simply manage this for authors, but until that happens, I thought I’d share a relatively simple workflow that has helped others. (Warning: I will use the words font and typeface with careless abandon to semantics in this article, though I know the difference. I’m afraid the more sensitive souls among you may suffer apoplectic righteous indignation.)
I will walk you through this workflow step-by-step, but if you get lost, just look at the source code… it’s pretty self-explanatory.
@font-face
generator, and download the resulting package. This contains the webfonts, as well as some sample files (though not an example of how to use the files in SVG).*.eot
, *.ttf
, *.woff
, *.svg
) into the same directory as the SVG file that will reference them. (Note: do not confuse the SVG file in the FontSquirrel package for a content file; it is an SVG font, with no rendering content.)@font-face
style rule from the FontSquirrel package file (“stylesheet.css”), and put it in your SVG’s <style> element.local
value to the @font-face
style ruletext
elements, using the resulting font-family
. In my example, I also created a style rule for textPath
elements.Here is the resulting SVG using webfonts:
Since I’ve mentioned SVG Fonts a couple of times, I thought I’d leave you with a final note about what the future seems to hold for them.
SVG Fonts were added in SVG 1.0, way back in 1999, as a way to embed fonts in the same file, using vectors and all the capabilities of SVG, including separate fill and stroke (which could be gradients or other paint sources), and even exotic features like clip-paths, animation, and so on; Jérémie Patonnier has a great article on the topic. As cool as this is, it doesn’t necessarily work well with existing font engines… The Adobe SVG Viewer had support for SVG Fonts, and Opera and WebKit added support for the less-powerful SVG Tiny 1.2 subset as well; but Mozilla and Microsoft decided not to add support for SVG Fonts, and that limits their usefulness. It doesn’t seem likely that SVG2 (being developed now) will include SVG Fonts, not necessarily even the more limited subset (though there is not yet consensus in the SVG Working Group).
In practical usage, SVG Fonts were once the only way to use webfonts on iOS devices (e.g. the iPhone and iPad), which is why FontSquirrel includes them in their font-face package; but this is no longer the case, and iOS 4.2 added support for TTF fonts, which reportedly perform better. I expect this use of SVG Fonts to dwindle away… people will naturally want to use as few font formats as possible.
But for all of you out there who, like me, love the cool things you can do with SVG Fonts that aren’t possible in traditional outline font formats, don’t despair! Even as I write this, a proposal is being prepared by the SVG glyphs for OpenType Community Group to add a subset of SVG to OpenType, for more interesting typeface capabilities.
SVG Fonts are dead! Long live SVG Fonts!
I have Libertarian friends who think Ron Paul has a chance at the GOP nomination… My intuition is that they are engaging in wishful thinking. My best guess is Romney will take it, but I’m hoping for Cain, for 2 reasons:
But should my guess prove correct, and Paul lose the Republican nomination, where would that leave him? He’s garnered quite a lot of support in some polls, and that might encourage him enough to consider splitting off again to run as an independent. After all, he is 76 years old, and may not have that many more chances to run (though he’s pretty spry), so he may as well throw it all in the ring for 2012. (Why independent and not Libertarian? He’s already got the Libertarian vote, and independent status might get him a few people who wouldn’t vote strict Libertarian… it’s a safer label.)
I would love this.
This is just a simple essay on how I see the world, and how I came to that view, the first in a set of posts I’m labeling philosophy. There’s no real point to it, no political or technical agenda… just some reflection and thinking out loud. I’ve never formally studied philosophy, and I’m sure these thoughts are probably not particularly original, but I arrived at them organically through my own life, in what passes for wisdom. Megan, my wife, laughs at me whenever I start a sentence with “I have a theory…”; apparently, I have a lot of theories. I have an active imagination, and I’m very opinionated; I like to try to figure out how the world works.
The way the mind works fascinates me in particular, and my understandings and beliefs about it have changed and evolved significantly through my adult life. I’m recording these thoughts now for the entertainment of some future me.
Continue reading “Speaking in the Third Person”
This week is our first Geek Week at W3C. The idea is to have a week where we improve our skills, collaborate with each other on prototypes and fun projects that help W3C, and to come up for air from our everyday duties. I’m working on a few projects, some small and some larger.
One of my projects is to make a plugin for Thunderbird, my email client of choice, which exposes the Archived-At email message header field, normally hidden, as a hyperlink. This is useful for W3C work because we often discuss specific email messages during teleconferences (“telcons”), and we want to share links to (or otherwise find or browse to) the message in W3C’s email archives. It’s also handy when you are composing messages and want to drop in links referring to other emails. (I do way too much of both of these.)
I’ve made extensions for Firefox before, but never for Thunderbird, so this was an interesting project for me.
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.
Anyone who has seen Tim Berners-Lee do any public speaking knows that he speaks very quickly. Too quickly, in fact, for non-native speakers, and some native speakers, to follow along. The words seem to tumble out of him, long after his mind has moved onto the next thing he’s planning to say, and the thing beyond that. W3C’s communications lead will frequently signal him to slow down, and Tim will step down to a slower-than-normal rate of speech and slowly build back up to his own “normal” auctioneer rate.
It’s not a coincidence that he’s one of the creators of the Web. From working with him at W3C these past few years, I’ve observed that his mind does seem to spin at a few cycles faster than the norm. He makes connections quickly, and even when I don’t agree with his conclusions, I admire his ability to grasp situations rapidly, and to revise his opinions progressively as he is given more information. He also shows a remarkable humanist take on topics, not just a technologist take. The Web, for him, was always less about the technologies involved than about the goals that could be accomplished with those tools; technology is necessary but not sufficient, just a means to an end.
And Tim is impatient to get to that end. It’s reflected in his rate of speech. It’s clear from the way he moved on from the solved problem of HTML (including XHTML and HTML5, mere refinements on the basic approach), to the idea of linked open data. People laughed at the Semantic Web a decade ago, and now companies like Google, Yahoo, and Microsoft are scrambling to put their own stamp on it, and governments are deploying it. Once again, Tim was ahead of the game, leading the pack.
On the W3C staff, we laugh about how Tim (or “timbl”, his email shortname and IRC nick) types as quickly as he speaks, with a cornucopia of typos. Sorting out the jumble is left as an exercise to the reader.
Some people can understand the spoken word at an astonishing rate. I once called a blind colleague, who listens to his screen-reading software at treble-speed, and he impatiently told me to speak more quickly. If you’re a seeing (and hearing) person, and you get a chance to listen to a blind person use their screen reader, prepare to be blitzed and dumbfounded. Paragraphs roll by at a modulated buzz, and you’ll be lucky to pick up a word or two; menu navigation is a staccato of half-spoken stutters as familiar items are tripped through like a stone skipping across water. Tim doesn’t speak that fast, thankfully… he speaks just fast enough that you have to listen carefully.
That’s why some of us on the W3C staff have developed a new unit of measurement: the timble. 1 timble is the uppermost rate of speech at which a normal person can understand what’s being said in their native language. On average, I’d guess most people speak in the range of 0.5 to 0.7 timbles; screen-readers are often operated at 2 or even 3 timbles; southerners (I live in North Cackalacky, USA) speak at about 0.4 timbles.
I recently teased TimBL about the timble at dinner in Bilbao, Spain, after he’d given a wonderful presentation at a local Web conference at a very equitable 0.8 timbles. He graciously offered an alternate definition: speech at more than 1 timble is difficult to understand; speech below 1 timble is simply boring.
Offered without comment.
Post about HTML5 logo and overblown “controversy” surrounding it:
1,078 hits on the first day.
Post about details on W3C touch events spec, including a roadmap and future plans:
273 hits on the first day.