Accessibility Standards
IDEAS 2008
The Interagency Disability Educational Awareness Showcase (IDEAS) is GSA’s premier event focused on partnering industry and education with government to meet the requirements under Sections 504 and 508 of the Rehabilitation Act.
Year after year, attendees of IDEAS gain skillsets through 508 focused agendas on issues such as electronic and information technology accessibility, 508 law and standards, website standards compliance, acquisitions, market research for accessible product and services, and more.
Also, IDEAS is a trusted venue for the latest exhibits of assistive technology products and services that help benefit employee service capability and reduce injury in the workplace. IDEAS helps forward the mission to enforce Section 508 across government agencies with the goal of promoting an electronic and information technology accessible government to people with and without disabilities.
IDEAS 2008 is the Federal government’s annual conference on Section 508, presented by the GSA.
Registration is FREE for government and industry and includes admission to all:
-
Keynotes
-
Educational Sessions
-
Networking Events
-
Technology Exhibit Showcase
Don’t miss this practical, hands-on educational conference and technology showcase on Section 508!
Apple Support Responds to Magnifier Focus Post
Originally posted August 28,2008
Apple support responded quickly to my Mac OS X requirement suggestions. Some of their responses indicate to me that they are not standing still on making their magnifier a state of the art tool for low vision users. Apple is a leader in OS accessibility and that is why I use a Mac.
- Provide text smooting. – Apple provides image smoothing but not text smoothing. When text is magnified beyond 4x, the user can see “digital jag”. The text has raged edges where the magnifier shows individual pixels. This could be resolved. Performance issues will have to be overcome. Commercial magnifiers have this feature. [Apple]: http://developer.apple.com/leopard/overview/ mentions Apple is already moving toward resolution independence which will ultimately enable on-screen elements to scale without jaggies.
- Provide a magnification spotlight. – This will allow the user to only magnify a small area of the screen. This helps with context. Windows allows the user to determine the size of the magnification rectangle. All magnifiers need this feature. The user should be able to toggle between full screen and spotlight quickly. [Apple]: Apple includes a developer tool called Pixie, that provides “spotlight” magnification in a window up to 12x magnification. (it’s on the Mac OS X DVD in case you didn’t install the developer tools on your Mac.) It ships with every Mac. Your thoughts on how it might be useful as an end-user application would be appreciated.
- Provide keyboard shortcuts. - Shortcuts should be one-handed. Shortcuts are needed for; toggling magnification on/off, moving the magnification focus up/down/left/right, switching from full-screen/spotlight and increasing/decreasing magnification. This would help with keeping magnified information in context. Sighted users who are working with visually impaired users would GREATLY APPRECIATE this support! [Apple]: Mac OS X provides shortcut keys for enabling and disabling zoom, changing magnification and smoothing, and provides for trackpad and mouse scrolling control of the magnification (press the Control key while dragging the trackpad or scrolling the mouse). Zooming is also enabled by default in Mac OS X.
This is good news about the text smoothing support. I will try the Pixie tool and report back on it. It would be nice if the Pixie tool could be made part of OS X and integrated with the magnifier as described above. Two magnifiers are not needed. I will encourage Apple to include additional shortcuts as described above. It is worth noting that Apple provides a real time magnifier that is ahead of competition. We will report on Microsoft’s response.
Magnifiers Need More Focus
Originally posted August 27, 2008
Both Mac OS/X and Windows Vista have magnifiers for their low vision users. Microsoft has added features that help the user place the magnified content into context. With limited resources, both Apple and Microsoft have moved the magnifier to the bottom of their list of upgraded feature requirements. They get their “ticky marks” for having a magnifier, however some focus is required. I would add this list of requirements to their development plans.
- Provide Text smoothing. – Apple provides image smoothing but not text smoothing. When text is magnified beyond 4x, the user can see “digital jag”. The text has raged edges where the magnifier shows individual pixels. This could be resolved. Performance issues will have to be overcome. Commercial magnifiers have this feature.
- Enable the magnifier to follow cursor movement. – OS/X has this. This should be provided by all magnifiers. The user should be able to turn this feature on/off quickly.
- Provide a magnification spotlight. – This will allow the user to only magnify a small area of the screen. This helps with context. Windows allows the user to determine the size of the magnification rectangle. All magnifiers need this feature. The user should be able to toggle between full screen and spotlight quickly.
- Do not use an on-screen preferences window. – Some commercial magnifiers have an on-screen magnifier preference window. This is annoying and requires the user to have to find it or worse, move it out of the way. Mac OS/X uses the System Preferences menu option to set magnifier options. Shortcut keys could remove the need for an on-screen window.
- Provide keyboard shortcuts. – Shortcuts should be one-handed. Shortcuts are needed for; toggling magnification on/off, moving the magnification focus up/down/left/right, switching from full screen/spotlight and increasing/decreasing magnification. This would help with keeping magnified information in context. Sighted users who are working with visually impaired users would GREATLY APPRECIATE this support!
- Provide navigation assistance. Shortcut keys are needed to move the magnification focus to vertical/horizontal areas of the screen as well as the next data entry control or default button. Scrolling shortcuts are needed as well. IBM OS/2 had this feature with their magnifier. IBM used the numeric keypad to move magnification and the mouse pointer to one of nine areas of the screen. What a help!
- Provide individual window magnification. – Magnifying individual windows on the desktop allows the desktop context to be maintained. The user does not have to turn magnification off/on or navigate long distances to find another application icon on the desktop. This is especially helpful to sighted users who are working with visually impaired users on their machine.
Assistive technology needs to keep up with the OS. Investment in assistive technology should be continuous. Apple and Microsoft have magnifiers. They need to be encouraged to do more.
Section 508 Needs Magnification Standards
Originally posted August 25, 2008
Section 508 – There is a need to update the 508 standard with consideration for low vision users who uses magnification to access web pages. The 508 standard contains detail about html tags to help screen readers, but contains very little for screen magnifier users.
Assistive technology magnifiers could use some additional features as well. For this post, I will focus on the web page design requirements to help low vision users with magnification.
- Use clean design and consistency in page layout. This helps all users find information and navigate quicker.
- Maintain context by grouping related information. This will help the magnifier user to find all of the related information quickly.
- Do not use roll-over pop-ups. Some popular news sites use mouse roll-over pop-ups to display additional information. Magnifier users use the mouse to navigate the magnified text.
Rolling over these pop-ups is not an optional event. Sighted users do not use the mouse to navigate a column of text and may never triger the pop-ups. Closing the pop-ups slows down consumption of information and causes difficulty in finding the place within the text to continue reading. In many cases, these pop-ups are not even relevant to the story. In some cases they are advertisements and are nothing more than web page spam.- Provide intra-page links to help with navigation. Remember, navigating a magnified page takes longer than a non-magnified page. Links for top, bottom, key items in list or FAQ items help the magnification user get somewhere useful quickly.
- Limit horizontal navigation time. By keeping a column of text within the view of a 4x magnified area, the user will not have to move the mouse to continue reading.
Try using a screen magnifier. Both Windows Vista and Mac OS/X have them as part of the OS. There are commercial products on the market you can get a trial version of also. Magnification is a tool that low vision users become dependent upon and you can design web pages to help them be more
Good Form for Forms
Originally posted August 23, 2008
Section 508 – Forms can be easy to make accessible to the visually impaired. Jim Thatcher’s blog post does an exceptional job of describing the necessary html tags to help screen readers and talking browsers deliver page content to the blind. Jim also points out how important it is to place labels close to entry fields and controls. This helps low vision users who rely on magnifiers to keep information in context.
There are additional things you can do to make your forms more accessible.
- Provide text at the beginning of the page describing the purpose of the form and the information requested.
- Provide a single purpose for the page. Keep other information for other pages.
- Keep clutter to an absolute minimum. Do not use additional advertisement or provide more information to confuse the user.
- Keep navigation simple. Do not have links for additional information as this may confuse the reader and make it difficult to navigate back to where the user needs to be to complete the form.
- Keep the form page static; that is, do not change the input controls based on user input. Do not use mash-ups or web 2.0 techniques for input on the form. Use large buttons that are easy to find for low vision page users.
- Be predictable. Do not change the style of entry from one page to another. If you are using rows for labels and entry fields on the first page, do it on all input pages. Buttons should be in the same place on all pages. If you are using buttons, don’t change to using links for submission of pages.
Accessibility does not start and end with screen readers. There are more low vision users who have to overcome magnification oriented contextual issues. Keep your form design simple and everyone wins.
Contrasting Color Is the Issue!
Originally posted August 21, 2008
SECTION 508 – There are obvious issues with color being used to obtain a user response or depicting information within a specific context. Section 508 calls for alternative graphic or textual information to obtain a user response or depict information. I am not color blind, so I am not personally affected by web pages that instruct the user to “click the green button” or “fill in the fields with the red labels”. But for color blind individuals, this is a significant issue. Fortunately, Section 508 has easy remedies for color blind accessibility. Jim Thatcher’s blog post does an outstanding job of discussing color accessibility requirements and resolutions.
For me, contrast is the real problem. Apple has popularized the “Aqua” look and feel and Microsoft Vista has emulated it to perfection. The Mac OS/X development team did such an outstanding job of making the innovative OS accessible and then they fell short on their selection of colors. To me, the Apple web site is another example of problems with contrasting colors. Combinations of pastel colors on a white background make it difficult for visually impaired web page visitors to find and consume information.
Section 508 calls for the presentation of text, (and images of text), in electronic documents to have a default contrast ratio of at least 5:1, except if the text is pure decoration. Large-scale text, (or images of large-scale text), must have a default contrast ratio of at least 3:1. Tools are available to analyze color contrast.
I have some questions about these requirements
- Is a contrast ratio of 5:1 adequate? If Apple and Microsoft are using a 5:1 ratio, it is not usable to me and many other visually impaired people I talk to.
- Is decorative text insignificant to the visually impaired? Decorative text has content, or why show it? Why isn’t there a functional equivalent?
- Why are foreground/background colors the only concern for contrast specifications? What about window border contrast to help distinguish one window from another? What about contrast ratios between buttons or links and background color?
- Should there be contrast specifications for rollover graphics? Graphic-to-graphic contrast is an issue, especially when the rollover implies an optional action that can be taken.
- Can size alternatives overcome contrast issues? People are always offering me magnification as a work around when what I am having is contrast issues. I believe I could drive a car if I could drive at night because of the fact that I can see lights better than shapes, (ridiculous example I know, but I can dream can’t I?).
- Why aren’t spacing requirements specified? Like contrasted items placed too close together can be very confusing to the visually impaired. I have significant problems with low contrast links placed too close together.
- Should color contrast requirements be specified for lists? I find it very helpful to have the beginning of list items differentiated.
For the totally blind, the 508 standards are adequate. For the low vision web user, the standards do not go far enough. Perhaps this will be resolved in the future.
Web 2.0 and Navigation Difficulties for the Blind
Originally posted August 15, 2008
SECTION 508 – Web page navigation can be an issue for the visually impaired. Clutter nad repetitive navigation links can keep the visually impaired from finding the main content of a web page. Section 508 calls for the web page designer to use a skip navigation link to help the blind reader find the page main content. Jim Thatcher’s blog post provides samples of how to design a web page for screen reader navigation. By placing a link at the top of a page, the blind reader can find the navigation link quickly and bypass listening to clutter, advertising and repetitive navigation information.
<a href=”#Main”>
<img alt=”Skip to main content” src=”1.gif” width=”1″>
</a>
… Search form, select menus, left navigation
… Right navigation content
<a name=”Main”></a>
… Main content
This works great for static, text oriented web pages. But what about?
- dynamic web pages that have content that is generated based on user triggered events? Can the “skip to main content link” access the dynamic content? The web page programmer should provide skip links based on the content generated.
- dynamic Web 2.0 pages that have ajax, dynamic HTML or java scripts? Alternative text information can help, but the screen reader cannot consume some of this information. The 508 and WCAG 2.0 standards call for the web page designer to provide an equivalent experience for the disabled. If possible, the web page designer could provide an alternative web page for the screen reader to consume. This would be at great expense to the web page provider and would most likely not be acceptable to the accessibility standards purest.
- web pages with multiple “main content areas”? When possible, web pages should be designed with a single purpose. The web designer should provide multiple links to the multiple task areas on the page.
- web pages with mashups or content from other web sites? As with dynamically generated content, the web page designer can provide skip navigation links to mashup content. The web page designer should try not to include non-accessible content from other sites.
Providing alternative content paths to offer an equivalent experience may not satisfy the purest, but I would swallow my pride and accept it if I could use the web site. More research is needed to see what others are doing to improve navigation within a page. Any comments or ideas?
Accessibility to Multimedia
Originally posted August 10, 2008
508 STANDARD – Multimedia content on a page must also have accompanying alternative text or a description. For audio, this includes a text transcript or synchronized caption for the audio. The transcript is not a separate file, but part of the page. Captioning helps the deaf or hard of hearing to comprehend the content. The captioning can also help index the page for search engines. The W3C introduced SMIL (Synchronized Multimedia Integration Language). SMIL is a markup language for closed captioning. RealPlayer and others have used the standard to provide manual formation of text for audio captioning.
DigitalChalk, Hunter College and IBM Research have built an automated transcription engine that creates synchronized text for audio and video files. DigitalChalk displays the captioned text and provides a real time editor for adding text for blind viewers of video. This function will be available 4Q2008. This work was the result of a grant from the National Institute on Disability and Rehabilitation Research (NIDRR).
Web Accessibility Test Tools
Originally posted August 5, 2008
The Web Accessibility Toolbar can help you test your web pages for accessibility.
- Web Developer extention for Firefox
- Web Accessibility Toolbar for IE
After downloading and installing the Web Accessibility Toolbar, you will
see the menu options.
- WAT – Update function and documentation
- Check – Quick check tools
- Resize – Convenient browser window resize tools
- CSS – Options to disable or enable parts of CSS
- Images – Options to explore alternative text information for images
- Colour – Options to test page color contrast
- Structure – Tools to analyze page structure
- Tables – Tools to analyze table structure
- Frames – Tools to analyze frame structure
- Doc Info – Information about page
- Source – Tools to view source
- IE – Tools for IE accessibility standards
- Log – Open a log for note taking
- FireFox – Open this window in FireFox
- Opera – Open this window in Opera
IBM Research has tools available to check your web site for accessibility. The accessibilityWorks tool works dynamically with the browser to check and correct the web page without human intervention.
It is not clear how these tools work with dynamically generated pages or how these tools can auto-correct alternative text for images. Web 2.0 remains a challenge for these tools as well. Web 2.0 tools should provide a means for page authors to add alternative information where appropriate.
Law to Shame Higher Education Looks to Pass
Originally posted August 3, 2008
OPINION – A bill sponsored by Mike Castle (R-Delaware) to shame higher education for high costs is expected to pass and be signed into law by President Bush. I do not think this bill is incorrect in its message. I think Congress could look at on-line education as a valid, lower cost alternative. To me, this bill shows a lack of imagination and vision. Troy University (on-line) in Alabama is serving thousands of students at a fraction of the cost of traditional colleges and universities. Community colleges are cost efficient alternatives as well.
Congress should be looking at:
- Making on-line learning accessible so all can attend.
- Improving learning standards and technology to cut costs and deliver education to anyone, anywhere.
- Providing tax payer funds to the most efficient with the best results.
- Providing support for needed degree programs that can improve our society.
- Cutting tax-payer support for those institutions you plan to shame.
Shaming wasteful and high cost education providers is appropriate. We can do more. I encourage Representative Mike Castle to contact us at DigitalChalk for answers!