I found a work around.  When the earbuds are plugged in, the screen sensor will not shut off the display.  So if I neeed an address while on a call, I plug in my ear phones.  I would rather have a preference setting to turn the sensor on or off.  Maybe in iPhone 3.0.

The Guild did have a thoughtful solution for their copyright concerns. The Authors Guild suggests, “The first step is to take advantage of a special exception to the Copyright Act known as the Chafee Amendment, which permits the blind and others with certified physical print disabilities access to special versions, including audio versions, of copyrighted books. Technology makes this step easy: certified users of existing Kindles could activate their devices online to enable access to voice-output versions of all e-books. This process could be ready to go within weeks.”

I don’t know about weeks.  I don’t know how serious The Authors Guild is about finding a solution when they accuse Amazon of a “rights grab”.  My company, DigitalChalk, values its partnership with Amazon and has found them to be very easy to work with and possessing the utmost of integrity. I have some questions for The Authors Guild:

1. Does the robotic voice of the Kindle threaten The Authors Guild professional book readers?  I would encourage the professional readers to show confidence in their skilled craft and not be afraid of the Kindle robotic voice.  No one wanting an audio book would find the Kindle text-to-speech entertaining or enjoyable to listen to.  Blind people find it necessary and are used to listening to less than optimal speech technologies.  I don’t think sighty would use the feature. Whatever you do keep the Zane Grey westerns coming with your so very talented readers that will entertain generations to come.
2. Should assistive technology not be allowed because of The Authors Guild rights?  Should all assistive technologies be eliminated because of copyright laws?  Amazon is not charging extra for the text-to-speech feature.  They are trying to make the text accessible.  I don’t see a rights grab.
3. Has the Kindle copied the audio books in intent, quality or packaging? Again, I would hope The Authors Guild products would have a higher quality reading for entertainment purposes.  If not, I would suggest that The Authors Guild find some new readers and not worry about copyright violations.
4. What is the process for certifying vision impaired users to use the text-to-speech feature of the Kindle?  Will the Kindle provide a retina scan, (I am being facecious),  or force me to electronically sign a legal agreement everytime I listen to a book?  Will I need a doctor’s note?

I would like to encourage The Authors Guild to think seriously about their litigation.  Please don’t do anything that would take this Amazon Kindle feature from the visually impaired.  I finally have a device that I can use to access text.  Thank you Amazon for caring about the blind!

1. Provide low light support – provide a white background for higher contrast.
2. Allow for larger font size selections.
3. Support font enlargement for lists and menu items.
4. Provide text-to-speech support for menu items.
5. Ensure that the Author’s Guild does not impact any of the existing text-to-speech features.

I encourage any and all who feel strongly about keeping the text-to-speech feature in Kindle to contact the Author’s Guild via email, or use the below contact information.

The Authors Guild

31 East 32nd Street, 7th Floor
New York, NY 10016

Phone: (212) 563-5904
Fax: (212) 564-5363

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.

1. 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?
2. 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?
3. Add text to speech.  It would be nice to have a screen reader.
4. The youTube application could use closed captioning.
5. 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?
6. The Notes application could use some navigation help for low vision users.
7. The Maps application could use a finger gesture magnifier, (like the one used to place the cursor in Mail).
8. 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.
9. I find the Blackberry text typing easier than with the iPhone.  The Blackberry has a superior user defined dictionary for text replacement.
10. 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.
11. Some of the application providers have selected low contrast UI elements.  Standards are needed for this as well.
12. It would be great if the App Store would designate applications as having met an “Accessibility” standard.   Apple could help WIA write this standard.

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.

Jason Hiner of ZDNet posted a list of nice features of the beta Google Chrome web browser. I agree with his list of five best new features. I do have a couple of accessibility observations though.

1. New Tab Page – features a page that shows thumbnails of your most visited Web sites, a list of your recent bookmarks, and a search box that allows you to search your history.   Hopefully, the history tab has accessibility alt tag support for the thumbnails. This tab could be a handy navigation aid.
2. Web Application Support – allows you to create desktop, start menu or quick launch icons for your web applications.  Hopefully these icons are 508 compliant.  This could be very helpful.

I hope this browser has assistive technology for the blind.  The increased speed could help make usability better for the sighted and those with disabilities.

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.

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

See DigitalChalk demo.

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.