You are reading an archived post from the first version of my blog. I've started fresh, and the new design and content is now at boxofchocolates.ca
Just in time for the holiday season – I’m honoured to be able to contribute to Drew McLellan’s 24ways.org with my article: CSS Background Images: Naughty or Nice?
Thanks to Drew and all the other authors for putting together a great resource so far!
About a month ago I wrote Browser Elitism and Browser Elitism Part 2. These posts saw fairly high traffic and got quite a few comments. So much so in fact that I didn’t find it very easy to comment properly and address the points that people were making in their comments. A few days after I set out to “solve” that problem, only to find out weeks later that Jonathan Snook had done something similar in his post Experiment with position: fixed.
Cool that we came up with similar ideas at almost the same time. Spooky that we only live about 10 minutes from each other. I love that the fixed comment form was integrated into Jonathan’s 78th redesign. I, on the other hand, am not quite ready for a full redesign, but wanted to implement the functionality right away. So, here it is – dockable comments.
Continue reading Dockable Comments: Intelligent DOM Scripting
I’m not sure how this post is going to come across, but I have to write it anyway. Feel free to comment or not comment at all. I’m not attacking anyone in particular, but in my mind there is some “unfinished business” to take care of as a follow up to my “Browser Elitism” post.
Some people said that I shouldn’t call it elitism, and that’s fair enough. After reading through the comments, I felt that something was missing that I couldn’t address properly in the comments. This is an attempt to consolidate my thoughts, respond to some points that people raised, and record it all so that I can move on (yes, there are things that are bugging me. No, I won’t lose sleep at night, but I do need to write it down).
The other day I was was encouraging a client to demonstrate their software’s front end web interface in Firefox rather than in Internet Explorer. (After all, I am all for getting clients on board using Firefox for their product demonstrations in sales calls or in meetings and for every day use.)
We were looking at a form that had a group of radio buttons for a choice, with a short paragraph nested below the label to further explain that particular choice. I implemented a :hover CSS effect on the div that I had used to encapsulate the radio button, the label, and the explanatory paragraph, which would only work properly in a “good” browser.
There has been a fair amount of interest lately in the use of weighted lists in tools such as flickr.
Jeffrey Veen mentioned weighted lists the other day, noting that this type of “folksonomy” has been extended to blogs as well, where it is being used to show category weight — blog categories with more posts receive a style that shows that there are more posts in that category. Nick has even put together a weighted list plug-in for WordPress.
This is all well and good and interesting use of technology. The problem with all of these implementations is that they return lists that aren’t lists at all. They don’t have a foundation of semantic HTML, and thus don’t even begin to address accessibility.
While thinking about weighted lists and some of the other projects we are working on, I thought it might be useful to give some detail on the thought process we use when coming up with recommendations and strategies for making things more accessible. Accessibility isn’t always easy.
These questions are our starting point:
So, lets apply that line of questioning to weighted lists and see what solutions come from the answers.
The answer likely depends on who you ask, but to me the most important is that it is used to provide a quick means to determine importance/popularity of a subject.
It provides information on relative importance of the tags/categories. It allows you to compare the importance/popularity of one item to the rest as a group, or an individual item to another individual item.
Ah, the tricky part. Most implementations of weighted lists that I’ve seen rely on visual styling to convey the information. This means that it won’t be accessible, and it doesn’t degrade gracefully. A screen reader user will not be able to get at the information — it is entirely contained within the visual rendering of the document, with no other means of getting the information.
Generally accessibility strategies fall into one of about three categories, and often include all of the following:
Lets look at flickr as an example (mostly because I have an account and have more experience with what they’ve done, not because I’m trying to pick on them), and how each of the above strategies help to make weighted lists more accessible.
Weighted lists are lists. This leads to a pretty clear choice in terms of semantic structure. Using either an ol or a ul make pretty good sense here. In this case, there is an order to them, so I’d suggest an ordered list, naturally. Once that semantic structure is in place, we can apply styles as needed to hide the list numbers and display each list item inline.
This provides better structure, but doesn’t necessarily help convey all the information. Visually, the weighted list lets us see which one is the most popular, and also lets us compare one term to the rest, or to other individual terms. However, a person using a screen reader will not be able to compare one term to another, nor to the group. A person using screen magnifier software may only be able to see one item on the screen at a time, making comparison based on size rather difficult. Lets address that next.
The weighted list is being generated dynamically by flickr. By default, it is listed in alphabetical order. It should be relatively trivial to create an alternate version that is ordered based on relative importance/popularity. Simply including a link to an ordered list ordered by popularity rather than alphabetically achieves this goal – helping people to determine where a specific term fits relative to the rest. (Alternate versions aren’t always bad.)
The weighted list also allows people to determine the popularity of a term in comparison to another term. In this case, it might be useful to include something that indicates the popularity of a term as it compares to another specific term. Comparing “cat” to “dog” may require more information. Knowing that dog is ranked 20th of 150 and cat is ranked 22nd of 150 give enough information to someone that can’t see them visually.
In this case, raw “scores” might be useful, and could be something that is placed in a span beside each term that can be styled appropriately. It could even be hidden and then exposed through CSS, or DOM manipulation, or through a link that leads to a page containing the data in (accessible) tabular format.
The techniques above will certainly help with those who need it most. However, the added benefit to making this a more accessible solution is that the application becomes more accessible and useful for everyone.
Some questions to finish off and illustrate what I mean: Can you tell the difference between text sized at 14px and text sized at 15px when they aren’t directly side by side? I certainly don’t think I could. What’s the difference in popularity between two things that share the same size in a weighted list? Are they exactly the same as the size implies? I don’t know, and with a visual representation only, you probably couldn’t tell either.
S5 is moving quickly – within the last few days, it has seen three revisions — the most important of which is seen in the 1.1a3 version with incremental display. If you aren’t aware, S5 provides a framework for creating well-structured and accessible presentation materials. We’ve been using Opera Show for our accessibility presentations at WATS.ca for the past year or so, but I was immediately attracted to S5 because of its cross-browser compatibility.
I decided to try S5 for a presentation I was giving last night, and I wanted a particular graphic to render incrementally. Here’s how I did it using the incremental display from the first alpha release to incorporate incremental rendering: S51.1a3.
Continue reading S5 and Incremental Rendering of Graphics
Just had my first article published over at A List Apart: Print it Your Way. The technique makes use of Chris Pederick’s Web Developer Toolbar extension for Mozilla Firefox, which he has configured to allow you to Edit CSS on the fly. This allows you to modify the CSS of any page on any site, and save those styles for later.
Continue reading Print it Your Way
My web development and accessibility consultancy is FurtherAhead, based in Ottawa, Canada, with clients around the world. And I'm not just saying that.