1. 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?
2. 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?
3. 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?
4. 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.

There are many improvements in WCAG 2.0, which W3C/WAI finalized in December 2008, as compared with the previous version.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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!

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.

1. Google and Jaws use alt tags and HTML tags to read pages for SEO and speech to text for the visually impaired respectively.
2. The same elements that a screen reader does not pick up are also ignored by search engine spiders, namely graphical images.
3. 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.

• 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.)

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

ideas 2008 registration pdf

Don’t miss this practical, hands-on educational conference and technology showcase on Section 508!

]]> http://www.learningaccessibility.com/blog/ideas-2008/feed/ 0 http://www.learningaccessibility.com/blog/apple-support-responds-to-magnifier-focus-post/ http://www.learningaccessibility.com/blog/apple-support-responds-to-magnifier-focus-post/#comments Wed, 01 Oct 2008 16:36:57 +0000 admin http://www.learningaccessibility.com/blog/?p=96 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.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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!
6. 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!
7. 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 – 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

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.

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.