And here we go again! sigh! Someone who doesn't want to use their  
brain, because "the screen reader should do it for them.
Already in the intro there was an error: They stated that the Mac  
couldn't be used by blind people until Vo came, how come then, that i  
as a blind user used and loved the Mac and Outspoken way back in 1993?  
I'm sure that most other errors have been mentioned already in other  
messages in this thread so i won't go on with that, other than saying  
that this is one of the biggest loads of crap i've seen in a while.  
Only thing i could agree about is that a documentation of VO and OsX  
keystrokes could come in handy, at least as an appendix.
/Krister

10 jun 2009 kl. 01.40 skrev Michael Reiser:

> Just thought I'd share this with everyone.  The nfb featured vo in  
> the june 2009 issue of the braille monitor.  While I agree with some  
> of the concerns here, I disaggree with quite a few especially that  
> vo should just read everything automatically.  Ironic that many of  
> the concerns put forth will be addressed in snow lepard.  Would love  
> toÎ hear everyone else's take on this.
>
> I'll paste the article here for easy reading.  Braille  
> Monitor                                                    June 2009
> (back) (contents) (next)
>
> Report on the Ease of Access of the Apple OS 10.5 Leopard  
> Environment with VoiceOver
> by Wesley Majerus
>
> <Wes-on-the-Mac.gif>From the Editor: Almost as long as computers  
> have dominated the lives of many Americans, some people have praised  
> the Apple products with a fervor verging on the religious. The  
> operating system has always been more visually intuitive than that  
> of the PC, and manipulating graphics on Apple products is apparently  
> both easy and satisfying. But since the Apple IIe in the early days,  
> which seems to have incorporated some speech access, Apple products  
> have been remarkably inaccessible to blind users.
>
> Now for the first time the Apple Macintosh operating system has been  
> equipped with VoiceOver, which provides more speech access than  
> blind people have ever had on Apple products. But how good is it?  
> How efficient is the speech? Does the blind user have access to  
> every computer function? International Braille and Technology Center  
> Access Technology Specialist Wesley Majerus set out to put the Mac  
> and VoiceOver through their paces. Here is his report:
>
> Apple's Macintosh computer is one of the only systems to have  
> integrated, full-function screen-access software. Because it is a  
> part of the operating system, it is usable out of the box and on the  
> showroom floor. You can simply walk up to any Macintosh computer  
> running OS 10.5 Leopard and press Command (CMD)+F5 to try out the  
> screen-access software. In this article I outline some of my  
> impressions of VoiceOver after the weeklong evaluation I recently  
> undertook. Throughout this document reference will be made to VO  
> keys or to pressing VO with other keys. These references are to the  
> VoiceOver keys, which are CTRL+Option and are held down in  
> conjunction with other keyboard keys to perform tasks specific to  
> the VoiceOver screen-access software.
>
> As I undertook the evaluation of VoiceOver's usability, I identified  
> several important tasks and uses for the Macintosh. These included  
> sending and receiving email; browsing the Web; downloading files;  
> and file management, including moving and deleting files. I also  
> wanted to know whether a user having difficulties could get help  
> from the Mac OS X help utility. Because creating and editing  
> documents is a central reason to use a computer, I evaluated the  
> TextEdit word processing application. In this article these tasks  
> will be presented in order of popularity. People are most likely to  
> use their computers for text editing, email management, browsing the  
> Web, and file management. These tasks will be described in this  
> article, along with our overall opinions of the Mac experience with  
> VoiceOver.
>
> For the most part blind computer users take advantage of the Windows  
> operating system for their computing needs, so they are accustomed  
> to the way that operating system delivers prompts, its keystrokes,  
> and its other characteristics. They are also accustomed to the ways  
> in which Windows-based screen-access software delivers information.  
> Because Windows is so entrenched in the blindness community, users  
> need a way to learn a new operating system. The manual that Apple  
> has produced, "VoiceOver Getting Started,” does not provide this  
> comprehensive introduction. Though it lays out the commands for  
> using VoiceOver, it does not explain how those commands can be used  
> in conjunction with OS X to make it friendlier. Email account review  
> and creation get no explanation of layout or use. It would have been  
> better to have a document that combines VoiceOver commands with  
> those of OS X so as to promote the use of the operating system  
> first, with VoiceOver acting as its overlay. As an example, many  
> Windows-based screen-access software manuals go into limited detail  
> about Windows and the way it works with the screen-access software,  
> especially in setting Windows and application-specific preferences  
> to make the screen-access software work better with the operating  
> system or the application. This is not done in the VoiceOver manual.  
> In Safari, for example, you can set up the browser so the Tab key  
> will move you between elements. This is not the default setting and  
> is not outlined anywhere in the VoiceOver documentation. In  
> addition, the instructions for using Apple Mail do not address how  
> to open or save attachments.
>
> We have a few other concerns in the training and documentation  
> department. The Apple VoiceOver tutorial is easy to use and is  
> straightforward to bring up. We like the fact that this is offered  
> and that it is integrated into the OS. VoiceOver has an audible  
> learning-mode, but the sound effects that VoiceOver provides are  
> often faint and difficult to distinguish.
>
> Two major problems with OS X and VoiceOver are consistency and  
> disorientation. As you are working with the system, especially after  
> editing in dialogs, you often can not tell where you are when you  
> are finished. Many Windows screen-access software packages signify  
> that a dialog has been closed by telling you the window title that  
> just opened or saying "edit" to tell you that you are back in an  
> edit area. They also say “menu” or “leaving menu” as you enter and  
> leave the menu. In VoiceOver, if you are completing a task that  
> causes the computer to work on its own without further input from  
> you, VoiceOver provides no automatic progress report to let you know  
> that the computer is still processing. However, if you focus your  
> VoiceOver cursor on the Progress Bar or other progress notification  
> area, it will audibly click by default whenever this area changes.  
> You can also change a setting in VoiceOver Preferences to have  
> changes announced, but it is important to note that your focus must  
> be on the Progress Bar or other notification area for either of  
> these announcements to occur. VoiceOver has keys that you can use to  
> move through an area. Sometimes in dialog boxes you can tab through  
> controls, but at others you must use the special VO keys. When  
> tabbing, you can often hear the control type (edit field, check box,  
> or popup button) but do not hear what type of information you were  
> to enter. If you use the VO keys, you hear control labels, but they  
> are separate from the controls and control types. From a keystroke  
> standpoint this means that, for each control in a dialog box, you  
> have to move to the right twice to get both its label and the  
> control itself. It would be more useful if the information in the  
> labels could be combined with the control types and values and if  
> you knew when you were required to use VO keys and when you could  
> simply tab.
>
> One other aspect of VoiceOver that is problematic is the lack of  
> toggle keys. In many screen-access programs you can toggle keyboard  
> help on and off by pressing the same key. In VoiceOver you cannot do  
> this because CTRL+Option+K turns it on, and then you have to turn it  
> off with Escape. This also happens in other places within the  
> VoiceOver environment such as with Scrolling Mode. In the event that  
> a password is to be entered, no feedback is given as you enter text  
> into the password field. In instances where you simply use the space  
> bar to check a checkbox, you do not get feedback about whether the  
> checkbox is checked or unchecked. A good example of this is on the  
> SMTP server setup page of Apple Mail. In dialogs containing lists,  
> you have to force VoiceOver to read the highlighted item. Moreover,  
> VoiceOver does not tell you how many items are in the list. When  
> working on the dock (the Mac’s version of the Windows task bar), you  
> can use CMD+right and left arrows to move items around. VoiceOver,  
> however, provides no feedback as you work. Clearly the program  
> should provide some indication that items are being moved, and the  
> item’s relationship to others on the dock should be described.
>
> Editing Text
>
> One of the primary uses for a computer, especially for new users, is  
> creating, editing, and reading documents. TextEdit is Mac OS X’s  
> primary document management solution. A few tasks are particularly  
> important: opening and navigating preexisting documents; creating  
> new documents; spell-checking documents; changing formatting; and  
> adding elements such as headers, footers, and tables. Opening  
> documents works fairly well using VoiceOver. The only problem arises  
> in dealing with the list of files and locations. Often in VoiceOver  
> you are forced to “interact” with an item, which means telling  
> VoiceOver that you want to work with this item and this item only in  
> a dialog. For a longtime screen-access software user, this  
> interaction is a new and foreign concept that adds more keystrokes  
> to an already keystroke-intensive system. Also it is never clear  
> when the user needs to interact with an item and when using arrow  
> keys or other means of manipulation is sufficient. Once the document  
> is open, you must figure out how to edit it. One of the issues that  
> cause Windows users most trouble is the way VoiceOver reports where  
> the cursor is when arrowing through, backspacing, or forward- 
> deleting text. Often, when arrowing across a line of text, VoiceOver  
> repeats characters multiple times and reports an incorrect character  
> under the cursor. When backspacing, it is difficult to know which  
> character is about to be deleted, so sometimes you delete the wrong  
> character. The same problem occurs in forward delete because,  
> instead of removing the character to the right of the cursor,  
> deletion begins with the character under the cursor.
>
> Sometimes, when you are inserting text into the document, the string  
> drops in at the wrong place because of incorrect character  
> reporting. Saving a document is easy, as is starting a new document  
> from scratch. Two aspects of the VoiceOver/TextEdit combo that cause  
> difficulty are document navigation and say-all capability. There is  
> no quick way to move to the top of the document or to its bottom  
> with a single keystroke as Windows provides. Later in our research  
> we found a new keystroke. In most edit areas you can use CMD+Up  
> Arrow to move to the top of the document and CMD+Down Arrow to move  
> to the bottom. The fact that this is an OSX keystroke further  
> illustrates the need for documentation that includes both OSX  
> keyboard commands and those for the screen-access software. VO+A is  
> the keystroke denoted for say all, which reads the entire document.  
> Unfortunately, no matter where your cursor is in the document, this  
> keystroke starts at the top and reads the entire document, unless  
> you are interacting with the scroll area.
>
> Throughout the operating system it is necessary to deal with data  
> presented in tables. This is especially true on the Internet and in  
> some text documents. VoiceOver’s tutorial outlines keystrokes that  
> can read a table by row or column. Unfortunately, this means that  
> the particular column or row is read in its entirety. There seems to  
> be no provision for reading the table cell-by-cell or to match the  
> data in particular cells to any column or row headers. Reading  
> tables this way can be quite confusing since making sense of the  
> data in the way it is presented is not straightforward. The  
> functionality to read a table cell by cell, reporting column  
> headers, has been available in Windows-based screen readers for  
> quite some time and is an important feature, especially in Internet  
> applications.
>
> Making a document look professional is an important use of a text- 
> editing program. This includes adding tab stops, headers, footers,  
> tables, and text attributes to the document. When you are adding  
> tabs by pressing the Tab key, VoiceOver will say “tab” and will let  
> you know where tabs are when you arrow through the document. It  
> provides no indication of how far from the left edge you have moved  
> with each tab as some Windows screen-access software programs  
> report. Blind users cannot add tables to a document. The tables  
> dialog, in which you define the rows and columns for each table you  
> want to insert, reads very poorly. Interaction and use of VoiceOver  
> Keys does not help remedy this poor reading. When adding lists and  
> text attributes to the document, you must first select text, as you  
> do in Windows. Take care when selecting lines of text because, if  
> you are not at the beginning of a line, using the select line  
> command will select text only from the cursor to the end of the line  
> and then to that position on the next line. The command VO+F6 will  
> report the text that has been selected. It would help if this  
> command had a more easy-to-remember keystroke, but it is good that  
> this function exists. When copying and pasting text, the system does  
> say “copied” but does not give feedback when the paste keystroke is  
> pressed. When you cut text, the Mac says “selection deleted.” It  
> should more appropriately say “cut” so that the user knows that the  
> text was not just deleted.
>
> Shortcut keys for adding text attributes like bold, italics, and  
> underline work from the main document window. Reviewing the format  
> menu allows you to see the checkmarks in front of options active in  
> the text under the cursor. It would be nice if, like shortcut keys  
> for adding text elements, a simple key stroke could add a list to  
> already selected text. This said, the menus for selecting types of  
> lists to be added are fairly easy to read. It is confusing, however,  
> for similar types of numbered lists. It is difficult to tell  
> whether, for example, you are adding roman numerals or arabic  
> numbers since VoiceOver reads both as “1, 2, 3.” If you want to copy  
> and paste styles, it is possible to do so using the copy and paste  
> commands and options in the menu. VoiceOver contains an option that  
> allows it to read text attributes such as bold, underline, or  
> italics as they change throughout the text. Though this works well  
> in a document, VoiceOver also reads the attributes of the text  
> within dialogs. Changing page options through the Page Setup dialog  
> is impossible with VoiceOver. Interacting with controls within the  
> dialog does not make them usable, and tabbing around the dialog does  
> not provide meaningful feedback.
>
> Spell-checking is another important task in document management.  
> Unfortunately, this is one of the most difficult tasks in the Mac  
> environment. One of the biggest drawbacks to spell-checking on the  
> Mac is the lack of a reliable option to check the entire document.  
> In most Windows-based scenarios, a user can choose such a function,  
> and it will prompt at each misspelled word in its own dialog box. In  
> this way the user can choose suggestions from a list and have them  
> spelled automatically. The spell-checker can be instructed to ignore  
> correctly spelled words in a single document or learn words that it  
> has not recognized but that are commonly used. On the Macintosh with  
> TextEdit, the user must deal with each misspelled word individually.  
> CMD+; moves from word to word. Once landed on a misspelled word, you  
> must use the Context Menu key VO+Shift+M to pick available options.  
> Words that are offered as replacements are not automatically spelled  
> as the user moves through them; this is a drawback because an extra  
> key must be pressed to make VoiceOver spell the highlighted  
> suggestion.
>
> When TextEdit lands on a word suggestion, it is automatically  
> highlighted. If you are distracted and forget that this is the case,  
> you can inadvertently delete the entire word by pressing any  
> character key on the keyboard. The Mac does have an undo keystroke,  
> which can be used immediately following the mistake if no other  
> action has been performed. The fact that a user can so easily delete  
> text is disturbing, however, because, if the user goes on to write  
> something else without realizing what has happened, the text is gone  
> forever. At times the CMD+; keystroke incorrectly reports the  
> misspelled word. It often reads the last misspelled word, which is  
> now correct, instead of the word the cursor is currently on. For  
> example, let’s say we have the sentence “Mary hda a little lbam,  
> whose fleece was white as snwo.” At the top of the document pressing  
> CMD+ semicolon should report the first misspelled word as “hda” and  
> should offer “had” as a suggestion. This first correction works  
> fine. Press CMD+; again, and “lbam,” corrected to “lamb,” should be  
> the next correction. However, often “had” (the word that was just  
> corrected) will be read instead. This continues throughout the  
> document.
>
> Browsing the Web
>
> Safari is the only Web browser that works with VoiceOver for  
> browsing the Internet. Internet browsing with Safari and VoiceOver  
> presents major problems. Two of these issues can be somewhat  
> mitigated by changing some settings. Under the Web area of the  
> VoiceOver Utility, ensure that "Move to It When Loading a New Web  
> Page" is enabled. In addition, in the Safari preferences, be sure to  
> check "Press Tab Key to Move to Each Item on a Webpage." This can be  
> found under Advanced Settings. Most screen-access software will read  
> a Webpage when it is fully loaded, but VoiceOver does not do this.  
> This is a problem because it is difficult to know when the page is  
> fully loaded, and the user is often interested in having the screen- 
> access software read the page content aloud automatically. If the  
> user wishes to deal with the page in more detail, he or she can stop  
> this reading or wait until it is finished and then explore the page.
>
> Detailed page navigation is extremely cumbersome with VoiceOver. As  
> it is set out of the box, Safari does not use the Tab key to move  
> between links and elements. With this setting changed, you can move  
> between the links and form controls on the Webpage, but at times you  
> are not interested in just the form controls and links. VoiceOver is  
> also set not to move directly to the HTML content area out of the  
> box. If this setting is not changed, the blind user cannot tell  
> where he or she is positioned or how to get to the page content.  
> Navigation by group is not accessible to blind users because the  
> information is not presented predictably or logically, so testing  
> was done primarily with VoiceOver set in Document Object Model (DOM)  
> navigation mode. If you want to browse the Webpage and are not  
> interested in just navigating through the controls, the process  
> becomes quite keystroke-intensive. First, one begins by interacting  
> with the HTML content area. To read the text, keep hitting VO+Right  
> Arrow. This reads the text and stops at any form controls. Then you  
> must hit VO+Right Arrow again to move to and read the link or form  
> control. Repeat these keystrokes until you have the information you  
> want. The process is painstaking, distracting, and cumbersome.  
> Keystrokes are available to move by headings or other page elements,  
> but they are not immediately apparent and had to be pointed out to us.
>
> Because the Mac help system is primarily based on HTML, these  
> concerns also apply to the Help Viewer application. While surfing  
> the Internet, it is necessary at times to download and save files.  
> Though Mac OS X allows file downloads, the process is ambiguous with  
> VoiceOver. When you click the download link, the computer  
> automatically downloads the file and places it in the Downloads  
> folder. No indication is given that the download has begun or is  
> complete. This leaves the blind user uncertain whether the file has  
> downloaded or the computer is encountering difficulty.
>
> Managing Mail
>
> Apple Mail is the mail-reading application in Mac OS X. When using  
> an application like Mail with screen-access software, a blind user  
> should be able to set up the mail account, initiate sending and  
> receiving new messages, read incoming mail, compose and send new  
> messages, attach files to outgoing messages, and deal with  
> attachments that arrived with incoming mail. Apple Mail setup had  
> one major problem. VoiceOver would not read the field labeled “full  
> name,” making the user unsure what goes in the field. Two areas of  
> the setup process contained multipage dialogs. To get to the second  
> and following tabs of these dialogs, the user needs to arrow to the  
> desired tab and then press VO+Space to activate it. It would be more  
> straightforward if there were only one keystroke to move to and  
> activate a tab. If the user only arrows to the tab wanted and then  
> moves away, nothing changes. The lack of audible feedback is  
> confusing because the user does not see the screen change so cannot  
> figure out why moving to the second tab does not bring up new  
> options. This problem occurs when editing the SMTP server list and  
> on the Account Information screen.
>
> We found a few problems with receiving mail as well. In each message  
> VoiceOver reads a long text string, including the words “unread,”  
> “body,” “subject,” and “sender.” If a field is blank, the title is  
> still read followed by the word “blank.” Though all of this  
> information is helpful, it could be more concise: "unread, john  
> smith, subject today’s meeting,” for example. Empty field headings  
> and the word “blank” do not need to be read as VoiceOver now does.  
> VoiceOver should also be reporting the presence of attachments as  
> the user looks through the message list. For example, “Attachment  
> John Smith, Subject Meeting.” If a message does have an attachment,  
> it is difficult to figure out how to save it to the computer. The  
> VoiceOver Getting Started manual does not explain how to deal with  
> message attachments. A detailed explanation of saving and opening  
> attached files should be added to the manual. In addition, the Quick  
> Look panel, which presumably allows one to preview an attachment,  
> did not read with VoiceOver. If you are using Mail with multiple  
> accounts, it is extremely difficult to know that mail has been  
> successfully received and into which mailbox new mail has arrived.
>
> Dealing with Files
>
> It is important to manage efficiently the many files that fill a  
> computer system. This is doable with the Mac, but we have a few  
> concerns. A user must be able to manipulate the table containing the  
> list of files, but doing so adds extra keystrokes. The Mac reports  
> that a file has been copied when you press the Copy command. Then,  
> when you move to the receiving folder to paste the file there, you  
> get auditory feedback that a transfer has taken place, but only by a  
> faint sound, no verbal confirmation.
>
> During testing we had to call Apple tech support. One of the first  
> things required was the system’s serial number, which was very  
> difficult to find. The technician did not know how to help a  
> VoiceOver user and could not provide clear instructions. This was  
> another instance in which I was not sure whether I needed to  
> interact with the data in the About this Mac window. I had to use  
> VoiceOver keys, which took a bit of time to figure out.
>
> Two other important applications are the address book and the  
> calendar. Calendaring is provided by iCal, Apple’s Calendar  
> application, which appears to be totally inaccessible to VoiceOver.  
> On some levels the calendar recognizes that the date is set properly  
> within the operating system, but VoiceOver keeps announcing December  
> 31, 2000. If you attempt interaction with the Calendar View part of  
> the screen, nothing happens. When you attempt to create an event,  
> the title can be entered, but arrowing, pressing Enter or performing  
> any other keystroke that might make progress toward entering other  
> event data seems to take us out to the Calendar window. Sometimes I  
> can find events, but I can find no pattern for doing so.
>
> We also tested the Address Book application that ships with OS X. It  
> was easy to look through the names of people already in the address  
> book, after interacting with the table containing them. We made a  
> mistake in the name area while creating an entry. It took a long  
> time to figure out how to tell OS X that an edit needed to be made  
> and more time to figure out how to get VoiceOver to work with and  
> manipulate the edit controls. Starting and stopping interacting with  
> various parts of the window and clicking options throughout the  
> menus finally allowed the edit.
>
> Summary
>
> The Apple VoiceOver screen-access software does allow blind users to  
> access most applications that ship with the Macintosh OSX Leopard.  
> Unfortunately, doing so is extremely keystroke intensive.  
> Calendaring is impossible with VoiceOver because nothing is spoken  
> automatically. The Interact process is both inconsistent and foreign  
> to screen-access software users. It also adds many more keystrokes  
> to an already keystroke-intensive screen-reading experience.  
> Browsing the Internet and using Mac help are two of the most  
> cumbersome tasks in VoiceOver because VoiceOver does not begin to  
> read automatically, and, even after interacting with the HTML  
> content area, one must continuously VO+Right Arrow to read even the  
> shortest text between links. Last and most important, the training  
> materials provided for VoiceOver should be modified. Background in  
> using OSX is not provided, and settings that make VoiceOver behave  
> better with applications are not provided anywhere. Though we liked  
> the fact that the tutorial for VoiceOver is tightly integrated into  
> the operating system and easy to invoke, we wish it provided more  
> tips on using OS X with VoiceOver as opposed to just highlighting  
> VoiceOver commands and not relating them to the operating system. As  
> tasks are undertaken, the screen-access software should speak  
> automatically. Examples of this are the newly loaded page in Safari  
> and progress messages while the system is working on long tasks.
>
> Though this report is based on Mac OSX 10.5 Leopard, Apple is set to  
> release a new operating system called Snow Leopard sometime this  
> year. Because VoiceOver is a part of the operating system, changes  
> will no doubt be made. We will have to analyze these tasks and the  
> new operating system, its features, and any changes to VoiceOver to  
> evaluate their completion. Anne Taylor, the National Federation of  
> the Blind Jernigan Institute's director of access technology says:  
> "Though we appreciate the fact that Apple has included the VoiceOver  
> screen-access software as a part of the Mac OS operating system, we  
> cannot at present recommend it as a productivity tool for the blind.  
> We cannot recommend any tool, even if it is free, if it hampers the  
> productivity of the blind user."
>
> If you are curious about the Macintosh and want to test drive  
> VoiceOver in a store or on a friend or colleague’s Macintosh, here  
> are a few keystrokes that might be helpful:
>
> CMD+F5 starts the VoiceOver screen-access software.
> CMD+Option+CTRL+F8 starts a brief VoiceOver tutorial.
> Finally, Pressing "VO+F8" (the VO keys are Control and Option) opens  
> the VoiceOver Utility to configure and customize the VoiceOver  
> screen-access software.
>
> You can learn more about VoiceOver at <www.apple.com/accessibility/voiceover 
> >. Visit the National Federation of the Blind access technology  
> Webpage at <http://www.nfb.org>, then click Products and Technology,  
> then Technology Center. If you have further questions, leave a  
> message on our technology answer line at (410) 659-9314, option 5.
>
>
>
> (back) (contents) (next)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To post to this group, send email to macvisionaries@googlegroups.com
To unsubscribe from this group, send email to 
macvisionaries+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/macvisionaries?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to