intertwingly

I would just like to know what this means: [link]

People who can’t see the image? My blind friend? If the image contains useful information why leave them short changed? Am I missing something here Sam, I’d have thought it obvious.

Dave: do you know of a single tool that does something meaningful with an SVG title when encountered inline in XHTML?  Unless there is a single tool that does something with this information, what may seems obvious to you seems entirely academic to me.

I know that many of my readers read my blog entries via feed readers or IE, and no matter how carefully I encode the data, these images go entirely unseen by all of them.  So, taking all this into consideration, I have always treated my icons as merely decorations.

Nothing wrong with decorations being decorations. I hope we don’t get into “all things on a web page must have meaning” crap.

But you could also annotate your entry in such a way that the topic the decoration represents is accessible, in both feed, and via screen reader. Perhaps a keyword annotation, or the use of RDFa, such as what I have at my site?

Actually I may have misread Mark’s snark, but I thought it was more directed at John than Sam (the tweet happened soon after his blog post).

Shelley, that’s actually a deep question.  One that I don’t have any ready answers to.  Some ramblings:

• You bring up the subject of topic.  Does the icon denote a topic?  I’m not 100% sure, but that certainly seems like a close enough approximation to be useful.  I started out this weblog eschewing titles and categories.  Over time, I warmed up to titles.  Now I may have stumbled into categories.
• Q: What could I do with categories?  A: I could search with them.  You do this with a hypertext link.  If I had that function, I think I would use it.  Probably often.
• You use dc:subject.  Alternatives include rel="tag" and category.  Each has pros and cons.  I can decide that one later.
• How would I expect this information to be presented?  Thinking for a moment on my particular use case, the easiest way to do it is redundantly as a text link.  Perhaps css and/or javascript could be used to hide the link or the SVG if the other is present, but if both show, that’s OK too.

I need to think some more.  This may need to wait until my mythical rewrite in Rails... all I did the last few days was some superficial reskinning.  I don’t currently index my entries in a way that would make this easy to implement efficiently.

Yeah, I was going to say that your clipart function as either tags or categories.  That’s how I roughly use them, though not always.  I have svg:title elements in most of my clipart files, but I embed them using the html:object (not inline).  I don’t put anything in my HTML fallback for that, and that’s probably bad...

Decoration ? Interesting. So the pictures are actually a visual help for visitors with reading disabilities. Visually impaired are not the only ones who deserve special attention on the web. Aphasics also. I call that accessibility! :-)

The accessibility orthodoxy does not permit people to question the value of features that are rarely useful and rarely used....

One advantage of categories, or a taxonomy, is that we can provide links to specific topics, such as I do for Planet RDF and my semantic stuff. We can also provide menu access, so people wanting to know more about a specific topic can browse through previous entries. Of course, a search form does the same, and probably more accurately.

Implementing all of this is a different beastie. When you’re using WP, you’re using categories. When you’re using Drupal, taxonomies are nicely integrated into the application. It becomes easy to use.

It’s funny, I’ve always seen your graphics as “categories”, setting a stage as to whether I will be interested in the topic. Not that I wouldn’t be interested in any of your writings, but I would be more interested in HTML5, CSS, SVG, JavaScript, PHP, etc, than I would Rails, which I don’t use.

It makes sense for me to use dc:subject, because I’m implementing RDFa now, and will be implementing it more deeply in a project I’m working on. For you, though, the microformat approach might be better.

I hear you on development, I have half a dozen little projects I want to finish. First, though, I really want to become proficient with Drupal. There’s so many darn nooks and crannies in the tool. Love it.

PS I really like your graphics. And no, I’m not going to add a title or desc to the inline SVG that forms part of my site theme. They are decorations.

Scalable Vector Graphics (SVG) 1.1 Specification > 5 Document Structure > 5.4 The ‘desc’ and ‘title’ elements:

Description and title elements can contain marked-up text from other namespaces

Any suggestions?

Dave: do you know of a single tool that does something meaningful with an SVG title when encountered inline in XHTML?  Unless there is a single tool that does something with this information, what may seems obvious to you seems entirely academic to me.

Consider the MathML that I have been using for the past 6 years on my weblog. All the accessibility experts touted MathML as the solution for accessible math. But at the time, and for years afterwards, this was a complete crock, as no AT actually supported MathML. It was not until a full four years later that DesignScience released MathPlayer 2.1 with math-to-speech accessiblity features. Still, once MathPlayer 2.1 did come out, it was a good thing that I didn’t have to go back through 4 years of blog posts to retrofit them with accessibility features. They “just worked”.

For the benefit of anyone else trying to make sense of this discussion while using internet explorer (i.e., me up until 10 minutes ago) things will make more sense once you visit the site using firefox.

From the First Draft of Action 54: Images of Symbols

"Markup images of symbols to identify the essence of what they represent or their purpose. It is usually unnecessary to describe the appearance of such an image or to identify it as a logo. Descriptions of what a symbol looks like would typically only be an appropriate text equivalent when it’s purpose is as an image (see images of pictures), for instance in the context of a page explaining the visual qualities of a well designed logo. If the symbol provides redundant or purely decorative information, the value of the alt attribute of the image can be null (alt="")"

I say skip accessibility on edge-cases unlikely to be used and just add a little blurb “email me at xxxxx if you can’t access some of the content on this site”.

Right now, I guess no-one using a screenreader will benefit from the text-equivalent of the SVG image today. But when browsers take that information and notify the accessibility interface (MSAA et al.), and the screenreader takes that information and presents it to the visitor, then the text-equivalent of the SVG will be perceivable to the screenreader user.

We, as authors of web content, are reliant on browsers to take our content and render it as best they can (or as close to the existing ‘standard’ as possible). The screenreader also needs to support the stream of data coming through the accessibility architecture or interface.

When all three components are existing and working, the content/text-equivalent of non-text content is perceivable.

When one component is missing, the entire chain collapses.

A markup author not putting in the title element of the SVG is one that fails to start that chain in the first place. Without the title element, browsers have nothing to use as a fallback, screenreaders have nothing to read through the accessibility interface. And there is nothing either of them can do to render the SVG image effectively to the site visitor if we don’t have the title element.

Yes, us content authors, are entirely reliant on browsers, operating systems/accessibility architecture and assistive technologies for a screenreader user to perceive our content.

Even though the browser vendor, the OS vendor, and the assistive technology vendor are currently failing to link up on this particular content chain, we should still do our bit because we need that starting point for the chain ever to be fulfilled.

It is a chicken and egg situation. I would suggest that it’s easier for the content author to start the chain, and that hopefully creates more pressure on the browser vendor to do the work they have to do to create their part of the chain, and so on until the chain is complete.

We’re in a mutual trust relationship. We have to trust the browsers, OS and AT to do the right thing. And they need to have trust that we, the content authors, do the right thing too.

@Laura, I’m unwilling to take the cop-out that these images are purely decorative.  (You didn’t suggest otherwise, but I’m just explaining my thinking).  I’ve tried to make sure that my posts are understandable by people who can’t see the images (well: most of my posts, this one clearly is an exception).

My current thinking is to go with redundant, and include this information a second time in textual form for all to see.  Once I’ve worked that out, I will see if somehow I can embed that into the SVG itself.

“It’s funny, I’ve always seen your graphics as “categories”, setting a stage as to whether I will be interested in the topic.”

+1 although I tend to read everything anyway and then spend a few seconds wondering about the implications of inline SVG on people who want to copy your images.

Writing and appraising  text alternatives is subjective. The content of the alternative text is subjective to the page author, and will depend on the role of the picture within the page. To determine appropriate text alternatives it is important to think about why an image is being included in a document. What is its purpose? Thinking like this will help an author understand what is important about the image for the page’s intended audience. Every image has a reason for being on a page because it either provides useful information, performs a function, or enhances aesthetics. Therefore, knowing what the image is for, makes writing appropriate text alternatives easier.

At times I’ve found it useful to categorize non-text content into three levels:

1. Eye-Candy:

Eye-Candy are things that serve no purpose other than to make a site visually appealing/attractive and (in many cases) satisfy the marketing departments. There is no content value (though there may be value to a sighted user). Never alt-ify eye-candy unless there is something there which will enhance the usability of the site for someone using a non-visual user agent. Use a null alt attribute or background images in CSS for eye-candy.

2. Mood-Setting:

Middle layer graphics which may serve to set the mood or set the stage as it were are not direct content and may not be considered essential, but they are important in that they help frame what is going on. I try to alt-ify these types of images  as makes sense and is relevant. There may be times when doing so may be annoying or detrimental to other users. Then try to avoid it. For instance ALT text that is identical to an adjacent text is unnecessary, and an irritant to screen reader users. I recommend a null alt or background CSS images in such cases. Best practice is to avoid redundant alt text. An example of this would be repeating the same text in your document, as well as in an alt attribute, and is unnecessary. Joe Clark  wrote about redundant alt quite few years ago. It is still true.

But sometimes, it’s important to get this content in there for all users. Most times it depends on context. The same image in a different context may need drastically different alt text. Obviously, content should always be fully available. The way you go in this a judgment call.

3. Content/Function:

This is where the image is the actual content. Always alt-ify content and functional images. Title and long description attributes may  also be in order.

The reason many authors can’t figure out why their alt text isn’t working is that they don’t know why the images are there. The key is  to figured out exactly what function an image serves. Think about what it is about the image that’s important to the page’s intended audience. Every graphic has a reason for being on that page: because it either enhances the theme/ mood/ atmosphere or it is critical to what the page is trying to explain. Knowing what the image is for makes alt text easier to write. And practice writing them definitely helps.

A way to check the usefulness of alternative text is to imagine reading the page over the telephone to someone. What would you say when encountering a particular image to make the page understandable to the listener?

Isofarro is correct mutual dependencies do exist. Two references thar speak to this are Essential Components of Web Accessibility and Accessibility Dependencies of the Successor to HTML 4.01

A way to check the usefulness of alternative text is to imagine reading the page over the telephone to someone.

There is no question to me that my archive page is more useful (as in easier to locate a specific post) when viewed by FF3 (which shows the SVG images) than when viewed by IE8 (which does not).

What I’m lacking is not an understanding of the problem, but the creativity necessary to envision a suitable alternative.  Until then, the page does degrade gracefully, and in a way that remains functional.

The footer (or right column watermark) SVG knot is floating up to the top in Gecko 1.8. Which is EOL, so I can understand not wanting to care about it.

Something that is mildly annoying is being told I’m a spammer, when the form remembers my details from a cookie.

James: try a refresh: I changed the style sheet.  Let me know if that fixes the problem.

And apparently, you haven’t posted since the server move, you’ve been reset.  The form is populated based on cookies.  In a few hours you should be back on the list.

Sam, in your archives, for the most part your image is redundant, because the titles you use provides the information equivalent to the image about the topic of the post. About the only place this fails is the Twitter posts, from what I can see.

Sorry if I’m slow, but I need to break this down:

You’ve seen the images primarily as a decorative element, as well as an experiment in, and promotion of, SVG. Others have come to use the decoration as a way of categorizing your posts. You’ve been reluctant to categorize posts, and so your intent was not to use the image this way. Now, you’re more amenable to categories.

What you need is less of a way to annotate the SVG, which you see as decoration, and more a way to equalize the reading experience for everyone, including those people who cannot see the SVG, or are using a browser incapable of rendering SVG.

I disagree with Isofarro, and I’m not going to add title or desc to my decorative SVG.

If the SVG performed a function necessary to the text, I would use the elements, and I would also use some form of text description outside of the image for those browsers that don’t have a clue about SVG; something such as one would find annotating a figure in a book. Chances are, I would also use an embedded external SVG file, too, to give users of IE at least a fighting chance of seeing the image.

If the SVG were separate stand alone SVG files, I would provide at least a title so that the rendering agent can use this as document title. I would hope to use desc, too. 

But the images I use are pure decoration, eye-candy, and are not stand alone. They could be invisible and nothing of my intent would be lost. People who are blind, or using IE (which would be equivalent in this instance) would not lose a thing accessing my site. Seemingly that was your purpose with your use of SVG, except that we have started adding meaning to them, so now you want to pave the cow path.

What you could do is use either microformats or RDFa to annotate visible text that provides category information, and then duplicate that within the SVG image. I’m not sure about how all this is going to work, though, especially since we’re not sure what’s going to happen when SVG is embedded in HTML5. In fact, isn’t what is in the title element an ongoing discussion in the HTML5 mailing lists right now?

So, you don’t necessarily need to annotate the inline SVG, and can continue to treat them as pure decorations. What you might need is a way of adding in the categorical information, to equalize the experience for all. In your posts, you can add category text, annotated with meta information how you see fit. But in your archives, where you don’t have a lot of additional room, one thing you could do is incorporate the category into the title in some way, such as Twitter:....

It really is up to you, though, because as you said earlier, you really didn’t want to get into categories. Except that, you really have when you started using a consistent image for a specific category of writing. Those of us with our eye sight and using Firefox have an advantage over the blind, and the IE user.

Ramble, ramble.

I’ve added something that is a pure decoration in the lower right.  Webkit sizes and clips it oddly, but Firefox and Opera do OK.  I’m quite OK with leaving that image without a title.

That said, I’m not willing to state that the images on the archives pages are redundant.  My two most popular/controversial posts this past month dealt with a potential job offer from Microsoft and my view of the state of HTML Working Group.  My initial post on the Microsoft offer had a follow up... how quickly can you find that post using IE?  How many posts related to Rails?

I’m not visually impaired in ways that impact my ability to read my site (I do use glasses for distance, such as driving), but even so, I have found this discussion to be (ahem) eye opening.

Sam, even with access to the images, there’s nothing that makes the two popular posts stands out, or more easily accessible. (Pun not intended.) For that you might want to use what we have access to with Drupal, which is a most popular content (of all time or for a specific time period) link section.

And a person coming in cold may not be able to decipher the images used, because sometimes you picked rather fanciful ones, rather than ones that are meaningful. And visual meaning is dependent on shared experienced, which is why text categories are typically more helpful.

Regardless, if you want to use title/desc, more power to you. Eventually, these will generate useful actions. I’m looking forward to seeing them change to reflect changes in the HTML5 document. It will be a short cut technique for all of us to keep up with what’s happening in the spec, without actually having to follow the mailing list.

Some questions to contemplate:

- Why is this non-text content there?

- What information is it presenting?

- What purpose does it fulfill?

- If you could not use the non-text content, what words would you use to convey the same function and/or information?

Shelley may have it with her category idea for the icons on your archive page. But you are the author, Sam. Think about it. You’ll find the answers.

“But you are the author, Sam. Think about it. You’ll find the answers.”

+1

I did want to say I also enjoyed, and been inspired, by this discussion.

Mark Pilgrim and Sam Ruby have been going back and forth and back again about accessibility and in particular the SVG images on Sam’s blog. In Mark’s latest post he explains the somewhat crazy world of access enablement: Long [...]...

Sam: yes, the stylesheet change did the trick. Although I’m being warned again, presumably because I’m at uni and hence have a different IP (I also have no cookie).