Accessible Folksonomies
2/27/2005
I’ve been working with web technology for over a decade now and I don’t think I’ve ever witnessed an idea gain mindshare as rapidly as the Folksonomy has. It seems like everywhere I turn someone is discussing this new categorization system.
For those of you who aren’t familiar with the term, a folksonomy is basically a taxonomy created by the people and for the people. A community of users collaborates by “tagging” various types of content with user created keywords. This concept is flourishing on a handful of community driven sites that all seem to have a certain addictive quality. I think the best way to fully grasp how folksonomies work is to dive into one of the sites that makes use of the concept. Flickr, 43things, and del.icio.us are good places to start. Given the success of these early experiments in group tagging I have no doubt that we’ll be seeing folksonomies implemented on all sorts of sites in the very near future.
Lately I’ve been thinking about one particular artifact of the folksonomy phenomenon — the folksonomy menu that serves as a sort of buzz index providing users with a quick visualization of the most popular tags (technically I think it’s called a weighted list). Popular tags are displayed in a larger font and it’s relatively easy to identify hot topics at a glance. This visual representation of the popularity of any given tag is undeniably cool. However, once the coolness factor wears off it becomes fairly obvious that these menus are also not very accessible.
I realize these sites are currently trail-blazers and they deserve to be recognized as such. I have no intention of detracting from the innovative work that’s being done. My concern is that once folksonomies enter the mainstream, the next wave of sites implementing them will likely begin a wholesale copying of the work that’s being done by these innovators — markup and all.
Also, I need to point out that folksonomies are community driven. A few minor changes to the existing markup would go a long way towards making these communities accessible to everyone.
Analysis of the accessibility of weighted lists on five websites using group tagging and folksonomy
I spent an afternoon looking under the hood of the folksonomy menus on following sites:
I was somewhat surprised to find that the markup on each of the folksonomy menu pages was entirely different. While all sites were basically implementing the same type of menu they all arrived at their respective results in different ways. Given this finding, I was even more surprised to note that each site shared most the same accessibility problems:
- Unstructured Links: With the exception of Technorati, each of these menus was rendered as an unstructured collection of links separated by only whitespace or a non-breaking space entity. It seems fairly obvious that these links constitute a list. Rendering these items as a list would provide visually disabled users with more feedback regarding the number of links as well as the ability to skip the list entirely.
- Extraneous Markup: While not technically accessibility related, each of these pages uses a fair amount of extraneous markup to achieve its goal. I encountered a startling number of span elements accompanied by inline style declarations. And while Technorati wins points for realizing that these links are actually a list, they should also win an award for the most creative use of the EM element.
- Absolute Font Sizes: Without exception fonts were defined in pixels. As a result I was unable to resize type in Internet Explorer. This was somewhat puzzling given the fact that it would be fairly easy to implement the font size variations using em’s. del.icio.us actually went as far as defining the font size in fractional pixels extended to the 13th decimal place. They must be using one of those 30 inch Cinema Displays :).
- Lack of Context: These menus currently require a user to actually view the page in order to discern the relative popularity of tags. There is no additional context that could be used to determine popularity. Given the fact that the difference in font size for any pair of tags can be as little as a single pixel, additional context would also be useful to those who are not visually impaired.
Recommendations:
The good news is that these issues are all easily fixed. Most of the solutions will be quite obvious.
- Use Lists: Lists have become the standard way of rendering a collection of links. Lists provide additional structure that can have a significant impact on accessibility.
- Avoid Inline Style Declarations: I’m sure there’s room for debate on this recommendation, but personally I would assign a class to each LI element. There’s really no reason for extraneous elements or inline style definitions.
- User Relative Font Sizes: Defining font sizes in em’s would allow users to easily resize type in any browser. Fractional em’s are easy to calculate, and they make more sense than fractional pixels.
- Add Context: While it’s not a perfect solution, it might be a good idea to add each topic’s relative rank to the title attribute of the anchor. Something like title=”Politics - Rank 3 or 10″.
- Consider Alternate Views: There’s no reason that the current standard folksonomy menu has to be the only way of representing the relative popularity of tags. An ordered list sorted by popularity would eliminate some of the need for visual clues. Adding a link to such a list would provide users with more choice while addressing accessibility concerns.
Here’s a page demonstrating my recommendations.
I realize that it can be challenging to focus on these types of details while innovating in the way that each of these sites has. While folksonomies are still relatively new, I think we’ve reached a point where it’s time to start thinking seriously about best practices.
9 Comments »
The URI to TrackBack this entry is: http://www.alttags.org/accessibility/accessible-folksonomies/trackback/
RSS feed for comments on this post.
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Good article. Consider additionally the potential of offering different views on the folksomony menu on the same site with different CSSs. If content and layout is properly separated (like in your example site) then different views on the menu can be realised, depending on user preferences and user disabilities.
Comment by Stefan Herzog — 2/28/2005 @ 11:52 am
alt tags : Accessible Folksonomies: Accessibility, Usability and Web Standards…
Trackback by linkages - avianto's quicklinks — 3/1/2005 @ 9:57 am
Regarding your inline styles argument.
I would argue that this might be one of the few times inline styles make sense because of the following reasons:
1. it is easier for developers to use scripting languages in markup then in stylesheets. (no need for setting up headers and bindings on the server - it is already configured and not everyone can configurate their server)
2. using classes with names like class=”rank-10″ / class=”rank-49″ or even “size-110pct” are meaningless and clutter the stylesheet, when values change, the whole stylesheet needs to be reloaded by the browser.
3. per 1: they can use percentages as font-sizes inline, which then obtain a semantic meaning, and as part of a list can still be scaled by userstylesheets on the (un)ordered-list element (also possible by using classes).
Furthermore it would be an accessibility improvement if the links or list-items would have their title attribute set to something meaningful (such as rank or percentage).
Comment by Sander — 3/23/2005 @ 6:52 am
Accessible Folksonomies
alt tags ≫ Blog Archive ≫ Accessible Folksonomies http://www.alttags.org/archives/2005/02/27/42/ メモ。…
Trackback by blog | bookslope — 3/23/2005 @ 8:20 pm
You raise a number of good points about the accessibility of folksonomy menus. Folksonomy entries themselves also suffer from this same lack of standards and use of semantic mark-up. This makes accessibility hard from the perspective of both people and machines.
I’ve started an attempt to create an xhtml microformat for folksonomy under the title xFolk. It would really benefit from further examination. Have a look here:
http://thecommunityengine.com/home/archives/xfolk/
Comment by Bud Gibson — 3/24/2005 @ 10:09 am
Great article! I checkeed all the popular folksonomy pages that you mentioned and all of them were able to resize the text in Firefox, so part of the problem might be IE. I also checked the pages with Denies’s WinEyes screen reader and they were readable. I doubt that a blind person is ever going to be able to grok the weight of the terms based upon the font size. I think a better method would be to put an actual weight next to the term … like “folkosonomy (32)” where (100) might be the most popular on the page. Imho, for a blind person a list is no better to tab through than a paragraph of links.
Incidentally, what WordPress theme are you using … it is spectaculay, i want it!
Comment by Seth Russell — 3/24/2005 @ 4:06 pm
Sander - thanks for the feedback. I want to stress that I don’t have all of the answers, I’m just proposing one possible solution. Your point regarding the difficulties of scripting style sheets is well taken. I suspect that’s one of the reasons the current group of weighted lists are implemented the way they are.
We’ll have to agree to disagree on the issue of inline styles taking on semantic meaning.
Bud Thanks for posting the link to your article! I just got back from SXSW where everyone was buzzing about Tantek’s presentation on microformats. It was quit thought provoking and it got me thinking that a microformat might be a good approach to the issues I raised in my article. I have to admit, I hadn’t gotten much further than pondering the issue in very abstract terms. It looks like you’ve already done quite a bit of work on this one. I look forward to reading your article.
Seth You are correct - font resizing is not an issue in Firefox. However, IE is unable to resize fonts that have been defined as an absolute unit. That’s a problem. Especially on weighted lists that use very small fonts. I tend to agree with your assessment of how the weight should be represented — either as a numeric value next to the term or as a value expressed in the title attribute of the anchor element.
One of the advantages of marking the links up as list items is that most screen readers will tell the user how many items are in the list (giving the user an idea of what they’re in for once they start reading the links).
Thanks for the compliment on the theme. It’s a custom theme that I created around the original design that Francey did for us a while back. She does great work.
Comment by Kirk Biglione — 3/24/2005 @ 8:24 pm
Folksonomy Visualization
MIT Media Lab’s John Maeda calls Flickr’s visualization of popular tags “the greatest diagram of 2004.” There are many things to admire about this format. Since it is about words,…
Trackback by DavidSturtz.com — 3/28/2005 @ 12:28 pm
Funny I should stumble on your post. I just myself implemented one of these “tag clouds” this morning. I never even bothered to study how Technorati or the social bookmark sites implemented theirs, I just sort of winged it. And although I’m not using a list, I seemed to have done pretty well on the other points you make. You can check it out yourself by visiting the link associated with my name on this post. Thanks for your insights. ~d
Comment by Douglas Clifton — 6/3/2005 @ 7:07 pm