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!

1. Provide an audio narrative describing the site.  It would be helpful to know what Facebook is all about.  Many adults know little about “Social Networking”.
2. Force the users to provide alt-tags for their images.  I know this sounds harsh, but photographs are an important part of the Facebook experience and it would be helpful if users would tag their images.
3. Provide help text for data entry fields.  It is not always clear how fields are used and when the fields are required.  Though most fields are self evident, there are times when I don’t know what Gacrbook is going to do with the input.
4. Improve Java Script usage for Screen Readers.  Most Web 2.0 applications have difficulty with htis.
5. Allow for larger fonts for the iPhone Facebook application.  This application is almost impossible to use because of the tiny fonts.  I do like the navigation though.

I find the buttons easy to use. I find the device very intuitive. The Whispernet feature is great and almost worth the purchase alone. I have not used the browser yet. The Kindle store is easy and too addictive. I have not read so many books since childhood. Customer support was responsive and very helpful.

If I were Amazon, I would build Mac and Windows OS versions of the Kindle application. It would help sell content. (I would be disappointed if the Mac app is not built.).

1. Screen readers keep everything within context.  Magnifiers lose context.  JAWS can provide the user with immediate lists of links, images, form fields and other web artifacts.  She can get that information instantly.  The screen magnifier user cannot.  
2. Jaws uses keyboard shortcuts for every access of the web page.  Magnifier users have to move the focus and hunt for things within a new context.
3. Magnifier users often are not aware they are missing information because they are only viewing a small part of the screen.  JAWS users can know all artifacts across a web page, (provided its is accessible).

There is the rub.  Not everyone values accessibility.  Rebecca and I depend upon it.  It would be great if others could design and implement web pages for accessibility.

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.

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

1. 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.
2. 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.
3. Make the buttons lage and high contrast.  Help the user know what the buttons are used for and where the buttons are located.
4. 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.
5. 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.
6. 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.
7. 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.

Using contrasting gray scale to contrast information is very helpful.  I like this use of contrasting color by the Safari browser team at Apple.  Notice that the search words are highlighted in white and the first word found is in yellow.  All other text has a gray background.  This helps put things in context and helps the user find the search word quickly.  This same feature could be used for other applications:

• Text editors – could use contrasting colors to help highlight the script construct being edited.
• Word processors – could use gray scale contrast to highlight the sentence and paragraph being edited or selected.
• Web Browsers – could highlight only the text or object being viewed, (as defined by the mouse pointer location).
• Photo editing software – could brighten the pixel area being edited and dim the rest of the photo.
• Code debuggers – could highlight the trace walk-back item and dim the other statements.

You get the idea.  This feature should be optional.  For many low vision users, contrast is a great way to pin-point something and make it obvious.

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.