Accessibility Standards
Video Closed Captioning Requirements
YouTube and Google both support automated closed captioning tools to add (cc) to video. Though this is a great move forward, there are some drawbacks to these tools.
- The (cc) text appears in the video. This can be a problem if the video provider does not want to display the (cc) in the video stream itself.
- The (cc) text is not easily editable.
- The (cc) text is not displayed at the word level concurrently with the spoken word.
- The accuracy appears to be less than 75% to transcriptions
Video closed captioning requirements include:
- Provides a video player and text display box that are separate.
- Displays text at the word level.
- Allows the video or audio provider an easy way to update the text while the video is being streamed.
Hopefully, DigitalChalk can provide these features this year.
ATIA Forum to Focus on Accessibility Business Case
]The 2010 ATIA Leadership Forum on Accessibility will be held January 28-29, 2010 at the Caribe Royale Hotel & Convention Center, Orlando, Florida.
At the Forum, you will find:
- The business case for providing accessible solutions to customer/constituents and employees
- Case studies from today’s leading corporations, government agencies, and educational institutions on successful accessibility integration strategies
- Targeted educational sessions for organization-wide solutions
- Access to 125+ assistive technology exhibitors
- Networking with IT and AT company accessibility executives and your peers.
I think this will be very interesting to see how accessibility is justified at the business case level. I would present the topic from a web technology point of view.
- Simplified software development and productivity through the use of plain text and less dynamic scripts.
- Improved Web Search Engine Optimization and Marketing (SEO and SEM) through plain text
- Enhanced website usability via accessibility fratures.
- Improved traffic from being inclusive to disabled users.
Accessibility makes good busines sence. I am looking forward to next year’s ATIA Leadership Forum
iPhone 3.0 Accessibility
iPhone Mail screen
Apple has not yet released any iPhone 3.0 accessibility information. I love my iPhone, but I have some recommendations for improving the UI for low vision users.
- In the Mail app, why not allow users to zoom the header of the e-mail message. If a user needs to zoom the body, wouldn’t they need to zoom the header information?
- In the settings, why not allow the user to set the font size for all applications? Why only allow font size settings for just some of the applications?
- Add text to speech. It would be nice to have a screen reader.
- The youTube application could use closed captioning.
- The iPhone screen shuts off when close to your ear, (or face), when talking on the phone. This makes it hard for low vision users to use other applications while talking on the phone. I could plug in the ear phones to stop the screen from shutting off, but wouldn’t it be nice to have a setting to leave the screen on when using the phone?
- The Notes application could use some navigation help for low vision users.
- The Maps application could use a finger gesture magnifier, (like the one used to place the cursor in Mail).
- Maps could use voice navigation. You ask what for? Blind people don’t drive! (I have – it’s fun!) Well I navigate for other drivers a lot.
- I find the Blackberry text typing easier than with the iPhone. The Blackberry has a superior user defined dictionary for text replacement.
- There should be some application standards for button placement. For example, I find the Calendar buttons to close together at the top of the screen. I have trouble touching the “<” previous month button and the Calendars button. They are too close together. In other applications, the buttons are too small.
- Some of the application providers have selected low contrast UI elements. Standards are needed for this as well.
- It would be great if the App Store would designate applications as having met an “Accessibility” standard. Apple could help WIA write this standard.
The Future of Touch
CNET had an interesting artilce about the future of touch screen technologies. As with any new technology, innovation leads to acceptance, but I had some other questions.
- Standards – who is participating in touch screen user interface standards? Apple typically has not been interested in sharing its user interface technologies with others. Microsoft is not standards minded. Do we have to learn different touch screen gestures for all of our Operating Systems and devices? Can touch screen gestures be so obvious that standards are not needed?
- Applications – how can touch screen technologies be used for educational applications? Can people learn how to apply touch screen technologies without standards? Are there universal gestures that are not copyrighted that canbe used in all applications?
- Web Accessibility – how can touch screen technologies be integrated with other accessibility technologies? Can touch screen technologies be used with other assistive technologies to produce a better user interface? Can gestures be used to help blind users find user interface objects? Can gestures be used to provide blind users with ways to identify user interface objects?
- Alternatives – will device manufacturers provide alternatives to touch screen user interfaces? Apple has not done so for the iPhone. Other phone makers are following the iPhone.
It will be interesting to watch the role standards play as touch screen netbooks, phones and other devices become available in the marketplace.
IBM Interviews Judy Brewer of WAI
IBM interviewed Judy Brewer of the Web Accessibility Initiative (WAI). The WAI just released the WCAG 2.0 standard for Web Accessibility. Judy discussed the accomplishments of WCAG 2.0. Below is a snip from the interview.
There are many improvements in WCAG 2.0, which W3C/WAI finalized in December 2008, as compared with the previous version.
- WCAG 2.0 can be applied to any technology used on the Web, so it is more flexible for developers. For instance, WCAG 2.0 allows the use of scripting. WCAG 2.0 therefore opens up all types of Web content to be more accessible for people with disabilities and older users.
- The provisions in WCAG 2.0 can be more precisely tested. This enables developers to know when they have met the requirements of the standard.
- WCAG 2.0 was tested successfully across a broad range of Web technologies, languages, and types of Web sites before it was finalized; so, developers can use it with confidence.
- WCAG 2.0 is accompanied by extensive technical materials that provide developers with proven design approaches, but which also allow developers to use their own innovations to meet the requirements of WCAG 2.0, and to share their innovations with other developers.
- WCAG 2.0 was developed with input and implementation experience from all over the world. It is expected to become the unifying standard for Web content accessibility.
Item 4 above is of particular interest. No one will have an excuse not to implement WCAG 2.0. There are resources and samples available to help any development effort. If you have not read the IBM interview it is worth the time, ( WCAG 2.0 and the Future of Web Accessibility). Great post IBM!
Section 508 & SEO, Good For Each Other
Search Engine Optimization (SEO) is the process of improving the quality and volume of traffic to a web site from search engines via natural algorithms. Because effective SEO may require changes to HTML source code of a site, SEO tactics may be incorporated into web site development and design. The term “search engine friendly” may be used to describe web site design, menus, content and forms that are easy to optimize. ”Spamdexing” or the use of “link farms” to draw traffic to a web site from search engines degrade the relevence of search results and the user experience.
In many ways designing a web site for SEO improves the user experience as well as makes the web site more readable for visually impaired users who use screen readers. Think about what search engines do to index a page and what a screen reader for the visually impaired do to read a screen. Both the search engine and screen reader depend upon text to do their jobs.
- Google and Jaws use alt tags and HTML tags to read pages for SEO and speech to text for the visually impaired respectively.
- The same elements that a screen reader does not pick up are also ignored by search engine spiders, namely graphical images.
- Clear and well written text is easiest for a user of a screen reader to understand and it also makes for better natural language rankings in a search engine. Search engines use tools to analyze the language in a paragraph of text for ranking purposes. Better written text will naturally rank better in a search and will be more understandable to a visually impaired listener.
Want to improve your SEO? Make your sie Section 508 compliant.
WordPress Accessibility
I have been working in the evenings to make my WordPress blog accessible. I am testing with the Firefox Web Development Tool plug-in. This is not trivial. The templage that I started with was not accessible. I tried some of the acceible templates and found them either not to be accessible or not very attractive. I also wanted to maintain a look and feel with the rest of my web site.
Using the FAE rule set, I am close. Using the beta rule set, I am quite a ways from becoming accessible. My appologies to anyone using my blog. I will keep at it. I think it would have been easier to start from scratch. Here are my challenges for the remaining FAE rule set. I hope to have the blog accessible by December 1, 2008. Hang in there with me!
FAE Rule Set Violation
Designing Forms
Field and button layout locations are important for the visually impaired. Zooming makes keeping information in context difficult. Remember:
- Avoid horizontal white space between labels and entry fields. Minimize the user’s movement with the mouse when filling out forms. Keeping fields with labels is difficult when in zoom mode.
- Place the buttons vertically right below the last input field. Don’t make the user search way over to the left or right to find the input buttons.
- Make the buttons lage and high contrast. Help the user know what the buttons are used for and where the buttons are located.
- Avoid multiple column input if possible. Keep your forms in a clear vertical trajectory. I have actually been in zoom mode and skipped the second column because I did not know it existed.
- Keep your forms to one page if at all possible. If you need more than one page, use a “continue” button and take them to a new page. It is easier to go to the next page via a button than it is by scrolling the web page.
- Number your input fields and tell them on each page exactly where they are. e.g. “Entry fields 1 – 12 of 23, page 1 of 2″. This helps tremendously.
- Give immediate feedback on each page. Place a high ontrast message by the field and ask them for what is needed.
These design tips improve usability for everyone, not just the visually impaired.
IDEAS 2008
On November 14, I attended the IDEAS 2008 conference in Arlington, VA hosted by the GSA. The conference was well attended by government Section 508 coordinators and I was able to network with quite a few of the Computer & Electronics Accommodation Program (CAP) coordinators. The information I received on government buying procedures, Section 508 tools and web site testing was well worth the expense and time spent. Some things I learned:
- Section 508 is an unfunded Federal government mandate. Up until six months ago the mandate was not well received or taken seriously by most agencies. Section 508 is beginning to gain traction.
- If you have products and services you want to sell to the Federal government, you should be listed in GSA Schedule 70, Buy Accessible Wizard and file a Volunteer Product Accessibility Template (VPAT) form.
- Documents should be Section 508 compatible. This is as important as web pages.
- Closed captioning is required and more tools are needed in this area.
- CAP coordinators are a great help for impaired employees. They have budget for their clients and can make recommendations.
- It is not clear what the buying process or packaging strategy for product providers to the Federal government.
- The Federal government is committed to Section 508 at the implementation level. It is not clear at the Agency CFO level what the commitment is. (This was a main topic of discussion in the show floor.)
Relative Fonts
I have not posted in a while. I have been very busy getting my web site (www.learningaccessibility.com) to be accessible. I have done so and I feel good about that. One thing I noticed; not only are relative fonts easy to implement, but they do not behave as expected. If your user wants to use web pages with relative fonts, they should not change the absolute default font-size preferences for their browser. I did so for Safari. I saw strange results on Safari that did not match Firefox. I couldn’t imagine why the text on Safari was so large and why my page was so distorted. Visually impaired people use all the tools in their tool bag and the mix can be interesting. The result is that relative fonts do not mix well with altered absolute default browser preferences.
At first I was grumbling about relative fonts. I spent wasted time debugging the unwanted results. If you use relative fonts you should:
- Let your users know not to use multiple zoom methods that do not mix well.
- Make sure all of your fonts are relative. Don’t mix relative with absolute font-sizes on your web pages.
- Do not use font-sizes over 200%. This starts to distort the page.
- Use 85% to 100% for regular text font-sizes in order to avoid page distortion.
- Use the Web Development Tool on Firefox to find all of your font-size settings.
- Test your web pages on Firefox, IE and Safari to determine if you obtain the expected results.
- Test your web pages with browser text zoom up to 4:1 ratio. Your page should not be distorted within this range.
- Use relative div and table sizes as well. This will help when pages are manually resized with relative fonts.