clouds

Am I too late for this group to be active and interesting? I'm new to lt, and a screenreader user. I am interested in the accessibility of tag clouds. Most sr users don't turn on features that announce font and size changes as they read. It would simply be too annoying. Similarly, it is really annoying to check the font of each link in a cloud. I can't find any standards on this, and so we wouldn't have to worry about stepping on anyone's accessibility toes if lt experimented a little with better sr-accessible forms for clouds. For example, you could add one or more (potentially visually invisible) asterisks to the end of emphasized items. The sr would read the number of stars if it was below its repeat threshold. Is this topic at all interesting to anybody?

I'm very interested in questions like these, thanks for bringing it up!

I think a tag cloud with font differences works so well in 2 dimensions, because the larger items 'jump out' at you visually. My guess is that for one dimensional browsers like screenreaders and braille displays, ordering the cloud by frequency would be more user friendly. I'm not a screen reader user though!

Fortunately, Librarything already supports this in the user's tag cloud, where you can either sort the cloud by alphabet or by frequency. Unfortunately, this feature is not available in the tag cloud of the individual books.

If you do want to create a presentation of the regular tag cloud that works on a screenreader, I would go about it differently. Personally, I'm not a fan of changing the code to cater for specific browsers (either assistive technology or browser hacks). You never know what combination of technologies people use and you almost always end up having to create more exceptions. I prefer to keep presentation and content seperate.

Instead, I try to create solutions that use the stylesheets (CSS) that are specific to the browser types. For screenreaders, you can use the 'aural' media type to create a specific style sheet.

For example, you could create classes for each "font size" in the tag cloud, for example 'rare' and 'common' to keep it simple. In the regular CSS you would give these the appropriate font sizes. But in the aural style sheet, you could pump up the volume for the common class while turning the volume down for the rare class. You could even throw in pitch, making the common tags sound lower and more powerful and the rare class sound more squeeky and elusive. I would really like to know how this would work in practice though, I haven't seen or heard one yet . See http://www.w3.org/TR/REC-CSS2/aural.html for more on aural stylesheets.

Yvette

Thanks for thinking about this with me. In principle, I agree with you 100% about CSS being the proper way to approach this. The reality is that I suspect none of the major sr's respect aural style sheets. I could be wrong, but I've never run into one. It is possible that a dedicated accessible browser like HomePageReader can handle this, but i'm pretty sure JAWS doesn't, and I can't imagine how it would help a person using Lynx via a shell account. Also, you have to consider: if sr's did allow this kind of manipulation, do people really want their volume/voice/speed messed with? Unless it was quite standardized, people might also have difficulty interpreting the "display." That's not to say that it might not be the best way to do it in the future, but I think lt staff would also be more likely to adopt something quick and ... well ... you know ... dirty.

The reality of access is rarely what someone at the W3C or the building department thinks it is. Access always means different things to different people, and the trouble is that, even on the web, one size rarely fits all. I hope that lt can take some kind of creative action on this without getting too bogged down in details. Chances are that any experimental solution that didn't negatively impact the general user base won't result in *less* access to the cloud displays than we (blind people) already have.

Another thought (suggested by a colleague) is to allow a variety of sorting options for the clouds. One problem I'm having in coming up with ideas on how to approach this is that I'm not totally sure what info is being presented and whether or not I'm missing pieces of it due to my sr. I know that there are some font changes using em and strong tags, and that there are often numerical frequencies as well. What to the degrees of emphasis indicate? What are the parameters that get represented in tag and author clouds anyway?

Thanks again for your processing time on this. I think it's a really important issue.

It took a couple of days for them to return my e-mail, but Freedom Scientific 's tech support confirmed for me that JAWS doesn't respect aural styles. They did encourage me to submit a feature request... Maybe the thing to do is to start thinking about how to best use aural styles to represent clouds, and by the time the rest of the world figures out that there's a problem, the necessary display tools will be available and we'll have an approach ready. I must say that the idea of mapping attributes to TTS voices in order to represent different levels of emphasis or other weighting schemes via an aural style sheet is an extremely attractive concept. I guess It's just a little frustrating to be designing a UI for which few accessible display tools (read screen readers) yet exist. Can anyone recommend the current best way to render aural styles using TTS and other sounds so I can start playing with it?

Your comment that "the reality of access is rarely what someone at the W3C or the building department thinks it is" made me smile, since I used to be on the W3C working group for the web content accessibility guidelines so you were spot on!

It's too bad that aural stylesheets aren't widely supported yet. I don't know any browsers that support them (but it's not really my area of expertise). I do think they are the way forward though. And about people not wanting the website to mess with their audio: I think that will be a matter of getting used to. Users of visual browsers allow websites to mess with their color schemes all the time :-) When I first got online in 1993 all sites were black on grey and look where we are today. Good browsers will allow you to overwrite the website's choices anyway so nothing will be messed with if you don't want it to.

I think ordered lists are a very interesting alternative. The downside is that it is not possible to render an ordered list as a tag cloud, at least not using CSS. This means you would have to have two separate presentations. Not ideal but it can be done. However, if you were to add a different presentation, you might as well add more content, like the asterisks Polyphemus suggested in the first post.

Hi, Yvette. Can you explain why an ordered list can't be used for tag clouds with CSS? It seems to me that you could use a style sheet to specify display:inline and list-style-type:none. This would use an ordered list, but would make it look like existing tag clouds, provided individual list items could be classed with "frequent," and "rare," to draw from your earlier example. I'm not sure how much further that gets us in getting sr's to provide a usable display, but I wanted to understand why you think ordered lists are a problem.

Since my last post I've done a bit more reading on the general topic of aural styles, and I withdraw my comment that people don't want their voices messed with. Since the standard does provide a min and max volume, the user is still able to provide a dynamic range within which the user agent has some flexibility without overriding the user's volume settings. Also, Yvette's comment about visual displays being "messed with," all the time is well taken.

It seems that the only mainstream browser currently supporting aural styles (via a plug-in) is Opera. I'm downloading it now. I'll experiment with it and report back.

@Polyphemus

If I understood MikeCherim's suggestion correctly, you would use an ordered list to separate the tags into categories. In other words: they would be grouped by frequency and the order in the code would be by frequency as well. There's no way you can change that into an alphabetical order like in tag clouds using CSS.

Simple example in HTML of what I think the markup could look like:

<ol title="Tag cloud" class="cloud">
 <li title="Common" class="common">
 <ul>
 <li>romance</li>
 <li>thriller</li>
 </ul>
 </li>
 <li title="Rare" class="rare">
 <ul>
 <li>fantasy</li>
 <li>horror</li>
 </ul>
 </li>
</ol>

This would always render in the order: romance, thriller, fantasy, horror. You can style the first two to be large and the second to be small, but that doesn't make it a nice tag cloud to use for regular browser users.

Very cool that you were able to find a way to testdrive aural stylesheets. Could you send me a link to the plugin?

@yhoitink

Thanks for the example. I'm going to think about it, but you raise some interesting questions. Can you tell me briefly what makes a good tag cloud for a sighted person? How many dimensions can a single cloud comfortably support visually? Can you state some basic attributes that you think nice clouds share? This would help me a lot.

I recognize that probably there is some active debate about this in the clouds community (whoever they are...), so I hope others will speak up on this as well.

in other news, I downloaded Opera and was disappointed to find that, while there may be a plug-in to support aural styles (claim untested) it is not currently working at all with sr's. I found some posts on an Opera beta list indicating that they're working directly with GW Micro (makers of VocalEyes screen reader)to improve the situation. Nevertheless, I was pretty demotivated by the lack of any access, let alone aural styles. I'm going to think a little more about the direction of the aural styling and hope they deal with the problem while I'm thinking.

In the meantime, please help me dig clouds.

@Polyphemus

To me, a good tag cloud has the following characteristics:
* Alphabetical order of tags
* Significant changes in font sizes depending on the frequency, like a factor 5 or so between the smallest and the largest. This makes the frequent tags 'jump out' at you visually.
* Font sizes are relative to the collection, meaning the most frequent tag in the cloud always gets the same largest font size. It shouldn't matter if the most frequent tag in your collection is used 10 times or 10,000.
* Not too wide, not wider than half my screen. That's pretty inexact but I don't like to see more than 5-10 tags side by side.
* tags wrap at the end of the line, no artificial line breaks in there. If the user changes the font size or screen size, it should re-distribute the tags.
* some tag clouds have a cut-off, meaning they only show the top X tags. For some purposes I like that very much, like displaying frequently searched items on a website. However, for visualizing my own tags such as on Librarything I want to see all the tags and not just the frequent ones.

I know there are two separate-but-related threads going on in here (tag clouds and aural style sheets), but I'm going to comment on the latter because I don't have vision problems and can't speak to the tag clouds issue. As someone who uses a screen reader, I find it there are many well-meaning accessibility issues which actually cause me far more problems than they solve. Access keys are a big one for me. Like many individuals with accessibility issues, I have already designated every single keystroke possible into navigating webpages in the way that is most useful for me. A random website comes along and decides to be helpful and accessibility-compliant by adding access keys, and suddenly my basic navigation fails. It's as if they had added a new, "helpful" feature which took over mouse clicking and turned into meaning something it didn't. I have access keys turned off on all of my browsers.

I wouldn't be surprised if aural style sheets are similar. As you say, most individuals who have to deal with text-to-speech have probably set their voices and volumes to exactly what they ought to be to best accommodate that individual's accessibility needs. While the theory of expressing emphasis of the aural style sheets is a nice one, in practice I wonder how text-to-speech users would feel about it.

... Do JAWS et. al change their volume for increased font size? Because if so, that would be a solution to the problem, even though it is repugnant to my basic desire to make everything logic-driven instead of format-driven. Also, presumably you would put the increased font size in the style sheet, and I assume JAWS-using browsers browse with stylesheets turned off.

I just got back from a disability tech conference in LA. It's the biggest conference of its kind in North America, and I made a bunch of interesting contacts on the aural styles front. I managed to discuss it with high-ups at Mozilla, Opera, Freedom Scientific, GW Micro, and a few lesser players. Everyone agreed that aural styles are not at the top of their priority list... I think that we're a ways off from having to confront the issues that I and jadelennox are concerned about. For purposes of experimentation, I'm going to try to mock something up in Python just to play with. I'll let the group know how that goes.

@jadelennox

If aural styles come to be used at all there will have to be an override similar to the hot key override that you employ. It definitely would be annoying to have your voices doing things you didn't expect, so it is possible that people would disable (sic) aural styles. On the other hand, most sr users don't do a lot with different voices, so it probably wouldn't be overloading stuff that users have already defined.

I'm pretty sure that the best place to implement aural styles would be at the sr level so speech could be managed by a single entity. The sr would provide settings to allow the user to specify such things as min and max allowable speeds, volumes, pitches, etc. That would serve to keep speech parameters relatively close to what the user already finds acceptable. Still. People would almost certainly override aural styles if they were abused or used stupidly (which they might be). BTW: JAWS definitely uses and works fine with style sheets in general. And no, JAWS doesn't have a general method of increasing volume or any other speech parameter with font size. You can assign specific voices to specific font sizes, but you can't easily make a general rule like bigger = louder.

@yhoitink

Thanks a ton! That is exactly the kind of list I was hoping for. I really appreciate it. Incidentally, I took a look at the tag cloud code and was disappointed to see that the text size changes are done by making absolute size specifications using styles at the tag level. It would have been a lot easier (and cleaner) if it were done with classes and external style sheets. Relative sizes would have been nice, too. I know, I know: everybody's a critic. I'm sure they did what they had to do, but it will make it harder to eventually get the clouds into a usable form.