Here at RightNow Technologies, we are always focusing on product quality. We believe our hard work has paid off and improved our product in many areas. Accessibility is no exception.
Our QA department has a rigorous testing process and won’t rest until we’ve created the best possible web user experience for our disabled users.
We thought it would be interesting to share one of the accessibility issues that came up recently in our product testing. This issue illustrates some of the difficulties and challenges associated with making a product accessible.
In accessibility there are so many factors at play including: operating system, browser, type of assistive technology being used, screen reader brand, screen reader version, disability type and more.
A good example to share is one that we have recently been working through. During our regression testing for an upcoming release, we noticed a problem with JAWS 11 when reading a link that contains both anchor text and an image with alt text. The following link (which doesn’t go anywhere since it’s just for demonstration purposes) is an example of this:
Learning from the WebAs you can see, this link contains the anchor text “learning from the Web.doc” and an image with alt text reading “Microsoft word document”. When using the tab key in JAWS 11 to read the example link we found that just the alt text of the image “Microsoft Word document” is announced. This leaves out vital information about the link, namely the rest of the anchor text which reads “learning from the Web.doc”.
Interestingly, if you use the arrow keys to read the link then both parts of the relevant information are announced as expected. To complicate matters further, we found order to be important in this issue. If we were to change the link by putting the anchor text before the image, then just the anchor text is announced when using the tab key and not the alt text of the image. The following link is an example of this:
In our testing, we found that this only occurred in JAWS 11. In JAWS 10 both parts of the link are announced as expected.
We’re not exactly sure how much impact this would have on our screen reader users, because we suspect that most users use the arrow keys to read content, but if they use tabs then they would be missing information.
So, a product issue possibly, but not something we necessarily have the ability to fix. Regardless, these type of issues result in a lot of review and introspection during testing. You will be happy to know that our inability to correct something isn’t the end of the line for us. We thought that this discrepancy was important enough to submit an incident with Freedom Scientific, the company behind JAWS. We’re not sure yet if they’ll consider this a product defect and fix it in an upcoming release or not but we’ll let you know as things progress.
So we hope you enjoyed this peek into our QA process and can see that we try hard to research even the small issues and find ways to correct them so that all of our users have a better web experience.
I think use image as a CSS background is much better idea for accessibility. there is purpose to put in content. It’s only good for sighted user.
see this page to get what i’m saying
http://pooliestudios.com/projects/iconize/
I would like to know your comments here and in my email also
I think you should add image as a background in CSS not in HTML see here http://www.askthecssguy.com/2006/12/showing_hyperlink_cues_with_cs_1.html
Jitendra,
Thanks for your comment! We appreciate your perspective and ideas. Your comment gives me a great idea on how to get around this problem.
I think the most important thing in accessibility is to make sure that all information conveyed to the non-disabled user is also conveyed to the disabled user.
In this case, the images do convey information regardless if they are implemented in HTML or CSS. What makes you think that the icons are only useful for sighted users?
I looked at http://pooliestudios.com/projects/iconize/ and I like the CSS version. However, I think that it leaves out information for disabled users. They should know what type of document they are clicking on as well.
Having said that however, I thinks CSS can still be used as long as the information is conveyed somehow. For instance, you could use the CSS image technique and put some offscreen text in the link that says “PDF file”. That way all pertinent information is still conveyed to all users.
for an example of this, look at how webaim.org does their external links: http://webaim.org/standards/wcag/checklist (look for the Spanish external link)
They have a <span> inside their link containing the text “- External link”. Then the span is styled off screen like so:
height: 1px;
left: 0px;
overflow: hidden;
position: absolute;
top: -500px;
width: 1px;
This effectively conveys the image to sighted users and the text to screen reader users.
Great solution. Maybe we’ll try it.
Thanks again.
But if we add image of icon then if page has multiple pdf’s and we add different icon to each pdf link then it will make code heavy while we can add icon in background via css sprite.
although your given information is good i have’t thought like that. Can’t we give this information that linked file is a PDF file in link like title=”PDF, 30KB” or in Link text itself Learning from the Web, PDF, 30KB
For flag like http://webaim.org/standards/wcag/checklist We can also use this http://piterpan.ru/silk-flags.php?l=en
I agree about the performance concerns and I think you have a good solution by adding the pertinent text in the text of the URL. I think as long as all information that is conveyed to the sighted user is accurately conveyed to a sight impaired user then using CSS sprites is a great solution.
this page is best example for what i was suggesting
http://www.adobe.com/products/reader/
see how PDF are linked under Developer sectionn