The Accessibility Testing Newsletter is a twice-monthly publication (second and fourth Fridays) intended to supplement training provided through the Accessible Apps project. It will contain information of use to both programmers and non-programmers. The Newsletter is sent automatically to AIS staff, and to other U-M personnel by request. Please send comments or questions to Jane Vincent, Assistive Technology Lead, .
Flashing content-usually cute animations or blinking text-used to be ubiquitous on web pages as a way to catch people's attention. Its use has declined, probably because site visitors found it more annoying than entrancing. But there's another good reason to avoid flashing content: it can cause seizures in people with photosensitive epilepsy.
WCAG 2.0 Success Criterion 2.3.1 says, 'Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.' The explanation states:
Individuals who have photosensitive seizure disorders can have a seizure triggered by content that flashes at certain frequencies for more than a few flashes. People are even more sensitive to red flashing than to other colors, so a special test is provided for saturated red flashing. These guidelines are based on guidelines for the broadcasting industry as adapted for computer screens, where content is viewed from a closer distance (using a larger angle of vision).
If you must have flashing content on your site, the Photosensitive Epilepsy Analysis Tool (PEAT) is a free tool that can analyze whether this content passes Criterion 2.3.1. If it doesn't, one standard work-around is to put the content on a separate page. Then put a link on the main page describing the content and clearly warning photosensitive people not to follow the link.
Coming up in our 2/22 issue: a Refresher on form field markup
We don't have the expertise, staff, money, or time to caption videos. Doesn't the ADA allow for exceptions because of undue hardship? The Department of Education, Office for Civil Rights doesn't consider captioning to be an undue burden, nor should you. There are a variety of reputable captioning services that will do the heavy lifting for you: Automatic Sync Technologies, Amara, CastingWords, 3Play Media, and Tech Synergy, to name a few. AST will both transcribe and caption your video at $159 per media hour ($2.65 per minute), with a standard 72-hour turnaround (they are usually much quicker than that). Rush pricing is also available. The other companies offer comparable services and rates.
Can I use YouTube to automatically generate captions for my YouTube videos for free?
Machine-generated captions (without using a transcript file) are of very poor quality (often comically so) and are not practical at this time. They are akin to the transcribed voicemail messages you get in email. You should replace these default 'captions' with captions that are actually useful. The reason for their poor quality is that the speech-to-text software used to produce the captions is not 'dialed in' to the voice in the video. State of the art voice recognition software, such as Dragon Naturally Speaking, requires the user to read a few sample paragraphs so that DNS can build a voice profile, which takes into account the idiosyncrasies of that user's pronunciation. There is no way to do that with YouTube.
That said, it should be noted that one benefit of machine-generated captions is that they can be used as a starting point for captioning your own videos. Even though the error rate for the transcribed words is unacceptably high, you can use a simple text editor to correct the errors, and YouTube has still synced the words to the video-a huge time saver.
Is it feasible for us to caption our own videos?
For shorter videos, certainly. The industry standard for time spent captioning is an average (depending on the volume of content) of 12 hours of captioning for each hour of video. That sounds like a lot, unless you've actually captioned your own videos! So, for a short 5-minute video, you can figure an hour's worth of captioning time. If this fits within your schedule and budget, then go for it. It's worthwhile doing a few times if only to become educated about the process.
Coming up in our 2/22 issue: Captioning FAQs, Part 3: how-to
Background: Imagine that you've just used your screen reader, speech input software, or other assistive technology to fill out most of a form. You're about to enter data into the final field and activate the send button...when the site times out, erasing all your work. This is frustrating to any user, but because of the more time-intensive nature of assistive technology use, people with disabilities may find this to be an insurmountable barrier.
WCAG Guideline 2.2 indicates four options for extending timeouts:
The guideline also indicates two situations where it would be permissible to not permit timeout extensions:
Question: Which of the following would not require a timeout extension?
Answer: #1 is the only example that meets one of the criteria for an extension waiver, since it is a real-time event with a required time limit.
There is no technical limit to how long the ALT attribute used to provide a text description can be; however, there is much disagreement over what the maximum length should be. My personal philosophy has become that ALT attributes should be no longer than 160 characters-the limit of a text message-because this forces web page authors to come up with succinct yet meaningful information.
However, there are some graphics for which 160 characters is far from sufficient. For example, bar graphics usually contain highly detailed information, all of which may be important to the reader. In this case, it's appropriate to provide a short ALT attribute (e.g., 'Bar graph of Michigan vs. Ohio State scores by year') and then point the user to a separate location that has a detailed description.
In the past, there has been a LONGDESC attribute for IMG tags. LONGDESC was intended to permit links to a longer description to be explicitly associated with the relevant graphics. However, LONGDESC is not supported in HTML5, and browser support is poor for earlier HTML versions.
The best current strategy is probably to put a link to the detailed description under or otherwise close to the relevant graphic (e.g., 'Click here for a detailed description of the bar graph'). The link may go to a location on the same page or a different page, as appropriate. The detailed description may be as long as necessary to communicate all important information.
This pie chart could be made accessible with an ALT attribute of 'Pie chart of U-M degrees granted in 2001' and with a link to a full description that begins, 'In 2001, a total of 178,101 degrees were granted: 22,350 in Education, 5,904 in the Visual and Performing Arts, 19,902 in the Humanities...' (etc.) Note that it is not necessary to describe any features of the pie chart itself, the instructions in the Legend, or anything except the actual data.
This is a complex screen shot from a site that provides step-by-step instructions. It shouldn't be necessary to provide a detailed description; instead, simply provide an ALT attribute that clarifies the current instruction. So if the instruction were, ''Type the student's ID in the ID field,' the ALT attribute could read, 'Screen shot of Find an Existing Value page. ID field is the first text entry field on the page.'
In most cases, this could simply take an ALT attribute such as, 'Photo of University of Michigan President Mary Sue Coleman in cap and gown.' However, for a site where it is important to know the details of the gown, there should also be a link to a full description that begins, 'A sash across the top of the gown is in a dark velvet approximating Pantone Color 19-4057 (True Blue). The sash has a half-inch trim in satin approximating Pantone Color 15-1049 (Artisan's Gold). The sash is worn so it drapes...' (etc.)
For the photo above, describe an appropriate ALT attribute and the beginning of an appropriate full description (if necessary) for the following situations:
Success Criterion 3.3.1 of WCAG 2.0 states, 'If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.' HTML5 has an attribute for required form fields that makes complying with this criterion very easy.
Remember that all form fields need a <label> tag that brackets the field label (e.g., <label for='goodeats'>Your Favorite Restaurant</label>, and an 'id' attribute in the <input> tag that matches the label's 'for' attribute (e.g., <input id='goodeats'...>. In HTML5, you can also add a 'required' attribute to the <input> tag (e.g., <input id='goodeats' required type=...>). Then if the field is left blank, the user will be prompted for input with an accessible popup balloon. For example, in Firefox submitting a blank required text field would result in the following prompt:
and not making a choice on a required field that has radio buttons would result in:
(Images from the Deque website)
According to the Wufoo website, the 'required' attribute is supported in Firefox 6+, Chrome 6+, Opera 10.6+, and IE 10+. It has unreliable support in Safari, and is not supported in iOS or Android.
Coming up in our 2/22 issue: Checking complex pages
For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent