Recently in Accessibility Category
Probably the best way to create a color blindness issue on a Web is to use Red/Green color coding. Even the latest WebAim Screen reader survey uses red and green pie charts. The good news is that the WebAim pie chart sections are labeled, but they still come out as a giant mustard brown pie in the Photoshop CS4 Color Blindness filter proofing tools.
One way use the color coding, but enhance usability for color blindness users is to bump your greens towards a blue. Blue is a good color because it typically appears blue to users with different types of red/green color blindness (the most common type of color deficiencies). So instead of a pie chart with lots of yellow slices, the color deficient users would see blue and yellow - which maintains a hue distinction.
You can see a demo below.
Red-green vs red-blue pie chart.
Same chart in protonopia color blindness filter view.
The first image shows two pie charts in which red is "Bad" and "Good" is green in the first version and a bluish cyan in the second. The next shows the charts in one of the Photoshop Color Deficient Proofing views. The red/green original becomes mustard yellow and brown while the red/cyan version has both blue and brown. Neither matches my original artistic vision, but at least the one where blue is maintained shows more of a difference.
How do actual users of screen readers behave and what do they want? The WebAIM organization has been conducting surveys in the past few months, and they recently released results from the second screen reader survey of 655 users. Some things I thought were worthy of noting:
Windows, JAWS & IE Still Rule
There wasn't an explicit question about Mac vs. PC, but when the top responses for screen readers (JAWS, 66.4% and Window Eyes, 10.4%) and browser (IE 6/7/8, 70.9%) are all Windows-only...you don't really need to. It's ironic that Internet Explorer is the most preferred browser, since it is known for its non-standard quirks and thus a major headache for Web developers. Nevertheless, it is still the standard for the screen reader community.
One visually-impaired user even considered a recommendation to use Firefox an accessibility barrier. If you need to learn a new interface by speech only, you could see that a switch to a new application is not necessarily a trivial matter.
Some Flexibility
On the other hand, there are some bright spots for the Web developers. One is that 8.9% of users use Apple's VoiceOver as their primary screen reader and 14.6% of users report commonly using VoiceOver. Apple appears to be a viable system for some users. Users are also willing to user Firefox and Safari. About 18.8% use Firefox as the primary browser and 39% report using it at least some of the time.
Other important metrics include how often the screen reader is updated and proficiency. Most users (83.6 %) have upgraded their browsers in the past year; this is important for Web developers since many accessibility code recommendations typically work only for newer screen readers. The more recent the technology/recommendation, the newer the screen reader has to be.
Proficiency is another metric, since many accommodations may require that users know to switch into different modes. For instance, JAWS contains table mode and forms mode where the special tags actually do their magic. If users don't know these modes, then a page would be considered "inaccessible" even with the technology properly implemented. Fortunately....only 4.7% of the users surveyed considered themselves beginner in screen reader usage and over half (52.6%) considered themselves expert.
On the other hand, it's not clear if the respondents are true representatives of the population. This was an opt-in online survey, so the population could be skewed towards more advanced users who are aware of the WebAIM organization or online accessibility resources. For instance, this audience is also 50% on mobile devices, which indicates a certain level of affluence and technological sophistication.
Social Media
Social media tools (Facebook, Blogs, YouTube, Twitter, etc) did fairly well. For most of the tools, over 50% of the users rated them as "somewhat accessible" or better. The two lowest scoring tools were LinkedIn (only 38.5% considered it "somewhat accessible" or better) and Facebook (58.7% consider it "somewhat accessible" or better). Compare this with Twitter which is rated 91% (with 61.9% of users rating it as "very accessible").
There are still concerns, especially if the tool is relying on Flash, but developers of social media are getting the job done, whether it be through standards compliance or through accessibility testing.
Problematic Issues
Technologies identified as being problematic included Captcha and Flash. Although Flash can be made accessible, the perception is that it probably isn't (62.2% agreed that Flash content was somewhat or very unlikely to be inaccessible). If nothing else, Adobe has a PR problem with the screen reader community (and probably a PR problem with the Web developer community as well).
Another interesting problem reported is "ambiguous link text" - that is a link whose destination is unclear out of context. The classic example are multiple "Click here" links. In principle, this is easy to solve, but lack of awareness means it's extremely prevelant...especially in a lot of content management systems which program canned link text statements. A good example of what to do can be found in Movable Type (i.e. Blogs at Penn State platform). The output generally includes distinct links including the blog title (which doubles as the permalink), tags and categories.
The last set of major problems included:
- Improper or missing image ALT Tags - A file name (e.g. Photo1356) is not a good ALT tag, but that's only option in tools like Flickr.
- Complex forms - Web forms (including login screens) can still be a major barrier unless they are properly structured.
- Unxpected screen changes - Web 2.0 tools need to announce when content changes. This can be implemented via ARIA (and Javascript) or some other technology.
- Poor Keyboard accessibility - I suspect this is going to be a bigger problem for Penn State as veterans enroll in college. Many may be having various hand mobility issues depending on their injuries.
Javascript Enabled...Sort Of
One preference Web developers will like is that only 50% now disable Javascript. Javascript can be accessible...so long as it is properly coded. On the other hand, there are still a lot of people disabling it, so you may want to use non-Javascript options for simple interactivity (e.g. non-Javascript date stamps, CSS rollovers vs Javascript rollovers).
Another good piece of news is that Skip Link technology has minimal impact. It should still be included, especially to skip the main navigational link block, but doesn't need to be implemented everywhere.
Use H tag Headers
An accessibility recommendation the community stresses is to break up content into headers (e.g. H1,H2....). In fact the survey indicates that most users (50.8%) prefer to scan though headers if the page content is long. That is, it seems like users still want a sense of overall information architecture. And don't forget the benefits of descriptive headers for your Google search ranking!
Images....Again
In terms of images, users definitely want ALT tags, even for decorative images (77.3%). So if your page has a cute cartoon lion, go ahead and describe him in the ALT tag.
A preference that may cause more of a headache are preferences for complex images (e.g. a bar graph or map). Web developers may be using the LONGDESC attribute or D link to send users to a different page, but most users (55%) actually want the description on the same page. But here, there is divergence - of the 55% mentioned, about half want the description right after the image (no link) and the other half want the description, but as an optional link. The remaining 45% either want want the link on a separate page (19.8%) or in the ALT text (19.8 %).
WebAIM says there is no clear consensus, but I do see a general preference for staying on the same page for the image description (either text or ALT tag) and not linking out (sort of like how visual users don't want to click a link to open an image in a pop-up window).
What you can do may depend on context. There are times when it makes sense to have a visible description for everyone, and others when you need to split the description for visually impaired users as a separate entity. The long ALT tag would be an ideal situation here, but JAWS may still have a 155 character limit (grrr). So....if you do have to go to a separate page for the image description, make sure you can link users back to the main text
A Positive Note
Any user of a screen reader can tell about the many problems encountered in everyday browsing, but the plurality (46.3%) feel the Web is becoming more accessible. It's slow progress, but at least it's progress.
I know I keep exclaiming that adding ALT tags to images benefit everyone, not just users on screen readers, but here is the perfect case of WHY it benefits users on visual browsers.
Here is a site in my bookmark archives which I apparently liked at one point. Today, though there were some problems with the images loading so this is what I saw:
So what was this site about? If you said Underground Railroad, you should consider becoming a psychic.
Now let's show a good example from PBS where ALT Tags are implemented. Can you tell where the images used to be? I'll let you ponder that. You should however, be able to determine that you are on a site about fireworks...even without ESP. You can also see that there is a main menu to the main PBS sites including a program listing and the PBS store.
Click Image to open larger image
Below is the same site with images displayed. The main menu is now a set of images and the header includes a nifty image of a firework shell exploding with embedded links. Although there is some extra information with the images, in terms of navigation, I would say the site was very functional without them...because of the ALT tags.
Click Image to open larger image
The first was given at the CIC Tech Forum conference on Oct 6 and discusses the challenges of implementing accessible content in an higher education environment, especially now that a "developer" may now be an instructor. A key factor is awareness, but ultimately the design of simpler tools is critical.
The second presentation will be given October 12 at the University Libraries as part of Accessibility Awareness Week. A few more concrete examples of accessibility accommodations are given.
Developing accessible PDF from a Word File on the Mac is sort of a trick question because the tool set is different than that on Windows. It's not terribly difficult, but you DO have to purchase the full version of Acrobat (I know, accessibility shouldn't cost this much). But if you have Word and Acrobat, here's what you can do.
In Word
Some tips for creating accessible content in Word are the following:
- Use a legible font - Times New Roman is a default, but it isn't so legible. Verdana and Arial are classic sans-serif choices, but you may want to try , but if you prefer serif text, you may want to consider Palatino or Bookman Old Style. I am also a fan of Chalkboard (versus Comic Sans) and Optima.
- Use Heading 1, Heading 2 styles - In many contexts, these Word styles will correspond to H1,H2 tags in HTML. Even if your Word file is headed for Dreamweaver, using these styles may mean they convert to H1/H2 in a cut and paste operations.
- Use the list tool in Word (instead of using Option+8 to manually insert bullets). Again, the list will be recognized as UL or OL lists in other documents.
Convert to PDF
I will assume that you will take the free option and print as a PDF file in the Mac print dialogue. The result is that text will be preserved as text, but it will not be "tagged" into levels according to Adobe Acrobat.
Printing to PDF is not inaccessible, but it is not as accessible as it could be.
Adding Tags in Acrobat Professional
Now comes the finicky part.
- Open the .pdf file you generated in Acrobat Professional 9.
- To see if a document is "tagged", open File >> Properties. In the pop-up, there will be a Tagged PDF field at the bottom. If it's set to "No," you have to add tags.
- Click OK to close Document Properties window.
- Now go to Advanced >> Accessibility >> Add Tags to Document. A processing slide bar will be displayed.
- To actually see the effects of tagging, so to Advanced >> Accessibility >> Touch Up Reading Order. You should see a pop-up window along with series of gray boxes with numbers in the upper right. The numbers indicate that the order the block will be read in.
- To add an ALT tag to an image, make sure the Touch Up Reading Order window is active. Then select an image and right-click (or control-click) and select the option to add an ALT tag.
There are more accessibility tools to explore including a Tag tab and the table cell editor, but I think you get the idea....
I've been exploring some accessibility issues and have noticed some disconnects in how accessibility can be implemented. It seems like that the community is making some critical assumptions such that 1) All online content is developed by professionals or that 2) everything is on a PC and 3) that developers are really going to manually disable Flash to check their content.
Online Content from "Non-Professionals"
One of the bigger challenges here at Penn State is that "online content" is actually being developed by instructors and students. In theory, we would like all "online course content" to be accessible, but if that were true literally then we would require that every podcast file be transcribed, every Office document & PDF file be tagged, every page generated by a content management system be accessible, and every image labeled with an ALT tag.
This can be done but it requires time and worse, some specific training. Yes, you can an ALT tag to an image in Word, but you have to know to right click and look for the "Alternative Text" field (and it only works on Window). Similarly, you can tag a PDF file, but you need to check the advanced menus in Acrobat (currently costing about $60) to make sure it is done right. This is much more difficult than clicking a "Convert to PDF" button (and more expensive as well).
The allure of the current online tools is that they are easy. Anyone can make a video, but right now only a few can make one with captions.
Mac Developer/PC User
An quasi disturbing accessibility trend I am noticing is lack of information/ability for Mac developers on how to make output accessible. Although most tools such as the JAWS screen reader assumes a Windows audience, it is a fact that many multimedia developers, particularly those for video or Flash are on a Macintosh.
This wouldn't be a problem except that the accessibility community seems to write many tutorials assuming everything is produced on Windows. The worst case is Microsoft Office which allows users to add ALT tags to images in Word or Powerpoint...but only in the Windows version. The only way an image in a Mac Word doc can get tagged is to export it to some other format, like HTML.
Many accessibility tools are also Windows only. There's an excellent Office Accessibility Wizard , but guess what...it only works on Windows. Admitedly, most users are on Windows, but again NOT everyone and possibly NOT developers who might be charged with this (because they are on a Mac). There are locations where multiple platforms are available, but not everyone's budget can support both...And in any case, it is a major inconvenience to switch between two platforms.
Debugging Flash
Perhaps one of the most serious problems facing accessibility is developing and debugging accessible Flash content. The good news about Flash is that it works across platforms. Which is why it is being incorporated into so many tools from YouTube to Adobe Connect and more. Flash video is truly the wave of the future.
The bad news is that building in accessibility is complex (you need to build in keyboard alternatives, alternative text descriptions for screen readers and check color contrast...somewhere in the application). Worst of all - it's difficult to discern if the developer has done this. Unlike straight HTML which have checkers like WebAIM WAVE and Cynthia Says, there are no tools to check Flash accessibility without doing something drastic such as disabling the Flash player or testing in JAWS.
There are lots of interesting Web 2.0 tools out there, but it's very difficult to evaluate if support for screen readers, captioning or keyboarding have been built in without checking the vendor specs or running it on JAWS. If you don't have JAWS (say, in a Mac only shop) and can't find vendor specs - you have to assume it's inaccessible. Too bad.
I may think the application is the coolest thing I have seen in a while, but can I recommend it? Sure, but somewhere in the back in my mind I'm thinking "We need a backup."
Dreamweaver Model
Although I am describing three different scenarios, they are symptoms of the same problem. At the moment accessibility is treated as a fairly arcane topic requiring lots of technical knowledge and even hacking of code.
I don't think it has to be this way. One reason I keep recommending Dreamweaver is that their accessibility tools are so easy to find and use. For instance if you drag an image into Dreamweaver, a pop-up window prompts you for an ALT tag. Once you fill in that field, you are done. There are similar prompts for forms, tables and even inserting Flash movies. I suspect that this strategy could be implemented in many more tools such as Word, Flickr or PowerPoint.
Expanding to Flash, could it possible to add more visible prompts to add alt text and keyboard alternatives? It sure would help developers understand that they should be there. The great thing about the prompts is that they recognize that accessibility should be part of the workflow, not an afterthought that only happens if a problem is reported.
Wrapping this blog post, I think my other point is that developers are an important an audience to consider. Browbeating them will only get the community so far (especially if "developers" include teenagers and busy instructors). It really is important to consider how accessibility tools can be just a little more accessible.
Click links below to download PowerPoint file of presentation and PDF file of links.
Here's a scenario familiar to many instructional and visual designers - an ambitious instructor (or other non-design savvy professional) creates a product that can only be described as well... hideous, tacky, amateurish or maybe just "needing a little adjustment." The colors may be too bright, the BLINK tag may still be in use, items may be moving randomly or an unusual cursive font may have been selected for the entire page. Or a video may be too long, text too technical for anyone but a graduate student or any number of common beginner mistakes.
The trick has been how to suggest changes without offending the sensibilities of the author. One strategy that can be helpful is to cite "accessibility." Even though there are well-established design principles that should be observed, they can seem subjective unless presented correctly. Accessibility, on the other hand, is becoming more familiar as a legalistic principle a lot of tech people try to comply with. They seem much more objective (while remaining exotic enough for authors to realize that this Web stuff has many facets).
And ironically, a lot of good design principles are also good accessibility principles. The blink tag is bad for people with epilepsy, and low vision users definitely need good (soothing) color contrast as well as standard sans-serif fonts. A lot of usability principles, especially in terms of consistency and structure, mirror recommendations for learners with cognitive disabilities.
Accessibility can also be invoked to explain why some "trick problems" should be avoided or why it's a good idea to provide some additional resources (e.g. PowerPoint lectures/Podcast). You're not making it "too easy" for students, but rather ensuring that diverse audiences are getting a chance to learn.
Of course, there are other ways to disseminate design theory to non-designers, but I am pleasantly surprised at how many instructors are genuinely interested and sometimes pleased to learn how to use accessibility to improve the overall design for everyone.
I would warn that accessibility should be used as a tickler and not as a threat. Although I have fallen into the trap of waving accessibility like a red flag, it really should be used as a yellow caution flag. In most cases, I feel that accessibility principles should be used to improve a product or lesson plan, but not be so cumbersome that innovation is blocked. Accessibility can evolve with technology.
I'm prepping for an accessibility presentation and realized it was finally time for me to bite the bullet and caption a video. I even set aside an entire afternoon for it. Surprisingly though it only took me about 2 hours (for a 2 min video) to input text, do the final adjustments and export the final product. And it was much more relaxing than I thought it would be.
Captioning Content and Tools
The video is from the Internet Archive, specifically a 1948 Pedestrian Crossing public service video from the U.K. government (midcentury educational videos are often entertaining). I downloaded the 512K MPEG/.
The tool I'm using is Parity (developed by colleague Pat Besong). It's free to Penn State users (and installed in our lab) and hopefully will have a more public release in the future. It works mostly with Quicktime files and right now is Mac only (which is a common platform for many video shops, although not necessarily for the average instructor).
Here's what a section looks like (warning you not to get distracted while crossing or "you'll soon find yourself in trouble").
This is a still image, not a video. Go to Export section to see video
Procedure
Parity has an option to either import a text transcript or let you start from scratch (as in this case). To start from scratch, you open Parity, create a New Project then load a movie into the view screen. You can play portions of the video within Parity as needed.
Once you load a movie, just start to play it and type in the black caption box. The great thing about Parity is that it will continuously loop a 4-second segment until you are able to complete a caption. This looping is actually huge time saver - a surprising amount of video time is actually wasted on pressing rewind, getting back to the right section then starting over. The looping really kept me in the captioning grove.
After you write a caption for the 1st 4 seconds, you can hit return to go to the next 4 seconds (which also loops). You can keep going until the end. The big gotcha here is NOT to hit the Return button to start a new line in the caption (because it kicks you into the next section).
Below is a view of the Parity screen with a series of captions and automatically generated time codes. Click image to view close up.
Editing Captions
For what it's worth, I recommend going straight through a video to get the bare captions, then worrying about spell checking and shifting words around later. If you have to go back and listen to a segment, move your cursor to the appropriate caption line, then click the Start button to start the looping process.
You can also shuffle text between lines as needed. One thing to look out for is duplicate captions (if you re do a section). Just delete a caption if you need to remove a line. You can also insert and split captions.
To make final adjustments, I used the "Preview in QuickTime" option to view the captioned video. I could decide to move text around then click the preview again until I was happy. Parity also lets you adjust font formatting and color, although the default is probably fine.
Export for the Web
What Parity exports is a caption text file which can be played in other files. For Quicktime (the default), it exports a .txt file (with the transcript & formatting) and a .smi (SMIL) file which is an XML file which calls the movie and captions and puts them together. As you can imagine the movie, SMIL file and .txt must be in the same directory.
There are other caption export options including Flash, Adobe Encore and others, but you have to manually convert a Quicktime video to Flash. I recommend an external track whenever posssible. That way you (or someone else) can edit typos or adjust formatting even if you don't have access to Parity at the moment.
A main exception is streaming Quicktime video in which captions must be burned or embeded as part of the video (ah well).
Final Product
The simplest result is probably Quicktime, so here is it is. I used the embed tag to link to a SMIL file. Click the play button to start the video.
"Grey Means go" (http://www.greymeansgo.com/) is a Website devoted to colorblindess issues in transportation and ways that traffic signals can be enhanced so that color blind users know which is the red light.
The site argues (I think successfully) that the new designs would make it easier for everyone. The author, Brian Chandler, cites crash statistics in some cases.
