Even when designing with our best intentions toward accessibility, it often takes someone who really uses accessibility software to test the site and help us get the details right. The problem is compounded when dealing with AJAX style behavior. That is exactly what happened with my jQuery FAQ example. What I thought was nicely accessible turned out to not be. This screencast walks through what I needed to do to fix it.
Links from Video:
- VoiceOver and Safari
- View Demo
- Download Files
- Dolphin products (Supernova & Hal)
That’s really educating! Thanks Chris.
BTW. In your answer link you use background-image and text-indent to replace the “Answer” text with this nice handle, so you can actually use “Reveal answer” also as a link text (not just title) and it will (or at least should) be read also by those screen readers that don’t read titles.
I recommend the training video ‘Web Accessibility Principles’ from Lynda.com
great stuff!
Thanks Eduardo! I’m Zoe, the “author” of that video title. If you wouldn’t mind sharing your feedback on the Amazon page (http://www.amazon.com/gp/product/159671395X) for others to benefit from, I would really appreciate it, and I think others would be able to get a better idea of if Web Accessibility is right for them.
Great stuff Chris! It’s good to see how you tackle a real JS problem when it comes to accessibility. Sometimes, though, I’d like to see the screencasts as posts instead.
Great tutorial as usual Chris!
It really shows that one should take these issues seriously and really think things over.
I’m a bit curious about users who have images turned off. Wouldn’t the answer button be completely hidden from them, since it is image based, and with the text being negatively indented?
Also, couldn’t you simply use the one definition list for all questions and answers? And last, but not least, I personally would probably make the “Answer” text part of the dd, and not the dt. Guess your could span it and just hide the rest of the answer away ’til you click the link.
Great tutorial, Chris! Sadly, I never think about accessibility myself. . .
When you click on the “Answer” links, the outline around it goes all the way to the left side of the screen, which looks a bit funny. I tested this in Firefox, but I also saw it in the video. The solution, as I am sure you know, is to put an “outline: none;” attribute to the “answer-tab” class. When I do this in Firebug, it automatically changes this into three elements:
I have no idea if you need all three or just the “outline: none;” but I thought I should let you know.
Setting your outline (:focus) is actually an accessibility thing so you can see where you are when tabbing through a page. For good practice you can set your :hover & :focus to the same thing so you’ll get that same mouseover effect on a link while tabbing through content
OK, that makes sense. Why does the outline sometimes leave the link or object, though? Like in Chris’s example, why does the outline go all the way to the left edge of the page? This has happened to me a few times also. Is there a way to fix that but still keep the outline?
The outline is caused by the text being positioned way off to the left, which is a common technique used in image replacement. In this case, adding the overflow property with a value of hidden to the answer-tab would force it to be no wider than its specified width. In other words the outline is still there, but won’t stretch to the left edge of the screen.
OK, thank you! That makes sense.
Some extra information I received in email and re-posting here with permission from Joe McCann:
Unfortunately, if a user is using Windows Eyes or the JAWS reader (the most common screen reader) and is not using a Mac and Safari (VERY slim market share %) then they will NOT pick up changes to the DOM, which is what you are doing with the slideToggle() method.
This has been a long standing challenge for making RIAs truly accessible. Current the WAI is working on a draft for a common API to communicate with Assistive Technologies such as screen readers to pick up changes to the DOM including AJAX responses. In the meantime, the technology is the burden as the technology itself will not actually “read” your answers after clicking on “Answer” button.
Screen readers parse the DOM on the page load and skip elements that are display:none altogether. To skirt this you need to use the visibility style attribute, but that will change the actual display to the sighted user.
The problem with this is the case where the user is using Assistive Technology AND has JS enabled. Screen readers don’t work like search engine spiders where the parse pages without JS applied, they scan the DOM the way it is “presented”, so unfortunately, it fails here as well, even if you setup the CSS to display: block/inline for non-JS users.
There are a few things to keep in mind with accessibility:
To design around all of these cases is incredibly challenging to say the least as the main issue is the actual technology itself (e.g. JAWS) has not kept up with the advances in the browser. So even though I can design and develop incredibly rich UIs and interactive elements, it has to work for all of the aforementioned cases, which truly stifles creativity and pushing the envelope. What we are seeing now with the meshing of the desktop with the browser as far as application and truly rich UIs is almost completely leaving out Section 508 and/or impaired users. Lawsuits will follow…I guarantee it.
You didn’t even check that you could keyboard tab through your original demo? And I’m surprised you were not aware of issues with the source order. It makes no sense to place an “answer” link after the answer itself.
What were the reasons for changing your original layout? You could have retained the same visual layout after you had corrected the source order.
To overcome the issue with hiding elements on page load you could try manipulating the height of the elements instead without adding display:none. Hiding the overflow will avoid bits and pieces sticking out from the element.
In addition, your example doesn’t work with images off because you have positioned the “answer” text off-screen.
Some basic tests involve checking with images off, javascript off, styles off, keyboard use, various combinations of these, and that critical elements are accessible to agents that do not recognise or alert their user to DOM changes. It’s good that you took steps to improve your demo and share your journey with your readers…but you should put more time into testing something before it is labelled as “accessible” :)
Great post Chris, I learned a few things for sure…
The one thing I found funny here is even in the fix you still came at it from a sighted point of view, in that you changed the “visual” position of the elements while changing just the HTML code order would have worked…lol
Visually you could have left the answer button where it was and the answer drop down where it was (which in my opinion “looked” better) for sighted users as long at the actual HTML code order was changed the screen reader would have stepped through them correctly, seeming to jump backwards on the page to the answer just as you wanted.
Alternatively you code have left the code as it was and added the tabindex attribute on the elements and your HTML order wouldn’t have mattered as long as the tabindex attributes were in the right order.
<element tabindex=”number”>
http://www.w3schools.com/tags/att_global_tabindex.asp
Another good read on the subject of accessability would be:
http://www.sitepoint.com/accessible-javascript/