Hi Folks,
I have a slideshow (http://test.vrmenterprises.com) that is strictly eye candy and I want to know if there is an alt tag for this type of graphic, or better yet an empty alt tag code. I put “empty” alt tags in images that are just decoration.
Basically, I want screen readers to ignore the slideshow and not produce any weird sounds that the reader/listener would find annoying.
Thanks.
VRM
There is no alt tag. <alt>like, whoa!</alt> You meant “alt attribute”.
You’re on the right track: decorative images get no alt text. You are encouraged to do it so:
alt=“”
Screen readers should ignore empty alt attributes. If there are title tags though, some readers may be configured to read those out, esp in the absence of alts. If any of the images are clickable, people using a reader will possibly be alerted that there’s an image as the reader may say “link graphic” (depending on the reader and configurations).
By keeping the attribute in there, you keep the validator happy, and it also keeps you sharp in remembering to add the attribute in at all times.
*edit: I don’t see any slideshow, but I also surf without Javascript. Be aware that while it used to be common to assume screen reader users don’t have JS on, recent surveys have shown the majority of people either have it on (because they’re just surfing through a regular browser anyway) or they don’t know if they have JS on (which likely means they have it on).
I understand that alt is an attribute, but how does a screen reader interpret a javascript produced slide show? While I do have a “noscript” message for those who have javascript turned off that if they want to see the slide show they need to enable javascript. However, I don’t know how a screen reader will handle the javascript. If the reader just ignores the script that’s fine, however, if it causes some weird sounds or attempts at interpreting, I would want to prevent that.
VRM
It completely depends on the HTML the Javascript adds (if it adds any). If there’s no text added, the reader should ignore it. Since this is a slider meant for sighted viewers and as decoration I think you’ll be ok… I just mentioned JS for In General, since you seem to be a developer who is aware of screen readers and cares (awesome).
One issue in the popular screen readers when there is JS is that the virtual buffer (the reader makes a copy of the text on the page, and that is what is read out and what the user interacts with when they use commands to skip around the page) doesn’t refresh when JS changes the page… the newest versions of JAWS and Window-Eyes do this better, although they are expensive and it’s good to assume people can’t always afford to upgrade. Orca screen reader doesn’t use a virtual buffer so I’d assume it just reads whatever’s after the cursor whether it was put onscreen by JS or not.
So anyway, if you have Firefox and the Web Developer ToolBar, put your JS on the site (if it isn’t already) and right-click, look for Web Developer Toolbar in the rightclick menu, choose View Source and then View Generated Source… you’ll see the JS-enhanced DOM (instead of the DOM of the HTML you wrote). That’s what any JS-using screen reader will be making a virtual buffer of. If there’s no text being added, then you’re ok either way.
Another side note: many people know that display: none is strangely honoured by most screen readers, even though something positioned offscreen or set to visibility: hidden does not (necessarily). However each reader seems to have its own quirky thing where sometimes, in special cases, something that is display: none does get rendered (read out). For JAWS, one of them was something weird like, an anchor who has a background colour with a display: none span inside, the span gets read out… or something weird like that.
So if Javascript were adding elements who contain text, and Javascript itself or CSS was being used to hide the element, it may, in some weird configuration of some screen reader with some bug, get read out. I also don’t think this will be a problem for you.
Another thing you can do is get one of the demo versions of one of the more popular readers and take a listen yourself, just to be sure. However if JS isn’t adding any text and you just have images with alt=“”, you should be good.
You can get a 40 minute demo of JAWS from Freedom Scientific (though that company has apparently stated that the they don’t like the demo being used by developers… bleh). You can get a demo of Window-Eyes from GWMicro. Those are popular readers for Windows only.
NVDA is a free windows screen reader and it’s slowly getting spread around the community, but developers seem to use it more than the average computer user.
If you have a Linux machine with the Gnome Desktop, you likely already have a copy of Orca, the free Gnome reader. You should be able to type “orca” into the terminal to get it started. So far I can only get it to react with Firefox browser though.
There are some other, older readers who are also popular, or were, but may be out of business (I dunno if Dolphin is still in business), but I think you’d be able to catch anything weird going on with just one of the Big 2’s demos. They do take some time to get used to.
alt=“” is also awesome for Mozilla browser users who have images off for whatever reason, since without alt text, it’s as if the image isnt there at all (no space is set aside to show there was an image, no border, no broken-image icon, etc. It’s simply Not There : )
Thank you.
The slide show and even the no script message were ignored. I only design one or two websites a year, so every time is like the first.
I had the pleasure of working at MIT for a while (that’s where I touched my first website with no training – scary but exciting). I was introduced to accessibility and usability by the Adaptive Technology Information Center (ATIC) lab. The folks there were great and one of the staff, who happen to be blind let me hear a screen reader. Well, at his normal rate it sounded like a bunch of bees, but when he turned the speed way down, I could understand. I also heard why the alt attribute is so important, who wants to hear the image file names. That is also where I became anti- “click here” links.
I still come up short when it comes to the tab access piece. Implementing that is not as straightforward. My sites seem to work pretty well with straight tabbing through because they are simple, however I could not develop a systemic way doing the tab access key thing.
Developing good websites is a journey. Folks at SitePoint help make it a little easier.
My other challenge is that I work on a Mac. I like my Mac.
Thanks again.
VRM
The slide show and even the no script message were ignored.
If noscript is ignored, then the browser you’re going through has scripts enabled. Which is fine. Also FF with NoScript, even if you are using NoScript to block scripts, the noscript tag often does not show (personally I think this is a bug).
That is also where I became anti- “click here” links.
Yes, esp if the user is going from link to link (you can go to Next Link, Previous Link, etc) or if the person has brought up a list of all the links on the page (you can do that too).
I still come up short when it comes to the tab access piece. Implementing that is not as straightforward. My sites seem to work pretty well with straight tabbing through because they are simple, however I could not develop a systemic way doing the tab access key thing.
Luckily, most screen readers have other navigation implementations, and Opera users can do spatial navigation (yay ++ Opera).
To tell the truth even when I’m using JAWS (and I’m not a regular JAWS user) I make heavy use of the quickkeys, like h for the headers, l for lists, f for forms/forms mode, t for tables. This is why good markup is important: screen readers are one of those few user agents who actually make use of good tag semantics. Use TAB just to make sure everything you want focussable is focussable, but know that a screen reader user is not limited to the Tab key.
My other challenge is that I work on a Mac. I like my Mac.
Then you have VoiceOver. Obviously it’s not going to work the same as the windows readers (every reader, like every browser, is different), but pretty much every Mac user is going to be using that reader. So far as I know it also makes use of the virtual buffer. You can get to it from the top left menu, somewhere there’s something called “Accessibility” where you can turn on all sorts of Desktop extras, and VoiceOver is in that list (I only vaguely remember this from a visit to the Mac Shop in Rotterdam : ) and unfortunately, while the OS was a Dutch version, VoiceOver was Engrish-only : (
Macs aside, you’ll still need access to a Windows machine if you’re developing a website, unless you know all the users are on some intranet with only Macs. You can either install Parallels or get a dual boot or possibly Virtual Box may work on macs (not sure). People often come to SitePoint stating a difference between Firefox on a Mac vs FF on Windows, so even browsers need OS-based testing (I have FF on my Linux box but I’ll still test FF on Windows too).