Hi, Sorry for this delay, I had intended to try out the Active State Perl beta 2 with the new graphical PPM GUI much earlier. As my post is more about screen reader and keybord accessibility than anything else, I thought I'd start a new thread just for clarity. Here we go:
Summary Even a cursory glance through the app revealed numerous keybord usability and accessibility issues. Although many are mere inconveniences and probably due to TK rather than PPM itself, there are still major issues preventing the application from being used by legally blind screne reader users. I would gladly test the application much further than this. However, as it stands now, there are numerous issues making usage both very slow and tedious. Spoken output, which is my primary screen reader output medium, is only useful in the menus and even the magnification fails to trakc the focus at large. Until most of the major issues have been sorted out, I'll gladly stick to ppm3 on the command-line for routine use. Once the GUI works well, I'm sold. System Configuration OS: WIndows XP SP 2 Pro English Screen reader: Dolphin SUpernova 7 professional (default application map file) Perl: v5.8.8 built for MSWin32-x86-multi-thread (with 31 registered patches The Menus ONe thing that I found very positive is that the screne reader has no major problems in the menus themselves. In fact this seems to be comparable to the access one gets in some of the Python apps written in TK. As the menus are one of those things that are currently accessible, they are the elements I can comment in the most detail. As far as keybord usage goes, many things, in relation to the list view, come to mind immediately: Major: 1. The main GUI appears to be a Windows style multi-column list view. As Windows does not have native keybord support for re-ordering, sorting, resizing and hiding the columns, these choices should be mirrored in the menus and dialogs for accessibility. Despite all its other faults, Outlook Express and Windows Explorer are two programs doing this about right. PPM does let you choose the columns but it provides no keyboard means for sorting, resizing and re-ordering them. As sorting and re-ordering can be performed using screen reader specific virtual focus (mouse emulation), setting the size is the only thing a competent screen reader user cannot do. One way would be to be able to specify the size of each column in percentages. This representation would scale across window Sizes and resolutions unlike the clumsy measures in Pixels Explorer and OE use. As to the other operations, sorting is easily achieved in the menus using radio-button style-controls. Re-ordering is customarily done in a diallog box with separate buttons for moving each column up or down. Toggling column positions with ctrl+shift+arrows would be a natural keybord extension to that interface, like dragging and dropping the items in the right order would be an intuitive mouse method. 2. Most menu items seem to lack both hotkeys and mnemonics. I mean those underlined letters as well as documenting shortcuts for common items like ctrl+c for copy. Unknown or not, most edit menus have the hotkeys listed. Minor: 3. Managing the visible columns is done in a sub-menu. This means that the user has to re-open the same sub-menu for each change. If the visible columns need to be changed frequently, a single dialog with a list of check boxes would be more intuitive. In his book About Face 2.0, Alan Cooper criticizes the use of sub-menus heavily in (ch 28). 4. While I am at this, let me Explore a pet peeve of mine a little. This is a minor thing really. I think the menu names are illogical. A package menu might be justified but there's nothing about working with files, conceptually, in the file menu. The same is true for editing, preferences are editable but cutting or copying is not editing, if you ask me. Sure enough this is a deeply held convention but I've aalways thought it odd. Cooper takes an even more radical approach and suggests not following guidelines when they don't make sense. I think the name action menu is a bit too generic, by the way. that's not a descriptive verb or noun for grouping things. But that's just my view. the List View It appears focus handling in PPM works decently, only muy screen reader tracks just the menus. I'm getting some problems with the list view, however: Major: 1. The screen reader does not track the moving highlight in the list view. 2. Holding down the down arrow key, I can see it highlighting the last item in the viewport (visible list portion). However, if I hit page down once or twice it scrolls but I lose sight of the highlight. The equivalent issue is there for the page up key. 3. Home and end do not work for going directly to the first and last items respectively, either. 4. If you are a keybord user, the only way to access a list truely randomly is typing one or more initial characters of the item name to go directly to the matching item in the left-most visible column. This is extremely handy in various applications and I use it daily in managing files, folders and e-mail. e.g. I can type in te to locate temp in the C-drive, no matter where the focus was previously in Explorer's file listing. Searching the list based on substrings does not seem to be working at all. 5. Sorting the list by a column seems to be very heavy and has major performance implications. WIth the screen reader, it resultss in a couple of seconds of starving as the screen reader process cannot get enough CPU time to speak or magnify properly, when the list is being sorted. COuld multi-threading the application further help? Minor: 6. The context menu for the list items has only one item in it. Further more, no item is initially selected. 7. In Windows apps like notepad, scroll bars do have context menus. The one's in TK do not appear to follow this convention. IT is useful as a clumsy sight-impaired mouse user, if you wish to scroll at the top or bottom of the bar and have no hotkey for it. Picking the choice in the context menu can be less challenging than dragging and dropping the tiny scroll thumb heavily magnified. 8. It would seem to me you can sort by the icon which is the left-most column. The icons all look much the same to me magnified. The bottom line should be, if it carries no meaning, sorting by it should not be possible. MAybe the icon being the left-most column stops substring searching the package name from working properly. Tab, Details and Search Major: 1. I'm glad to be able to report that the tab key changes between various fields and thus has a true tab order. yet again my screen reader is unable to ttrack the focus. Even with sighted help, however, we could not discover where the focus went visually, apart from the search field, package list and details view. What are the rest of the 10 items in the tab order? That is every 10th tab press takes you back to the same multi-column list. Is such a long tab order intentional? 2. The details you does have a cursor which means you don't need screen reader specific means for geting the focus there. However, the field does not show its affordances clearly. neither does the cursor change, nor are copy and the other functions available in the context menu. I think the field should also be grayed out (no hard-coded gray, however), like read-only text fields, to visually indicate they cannot be edited. 3. Being able to narrow down the selection in real time while you type, in spotlight or help index fashion is real cool. One nag about affordances again. There's no context menu for copy and paste in the search field and the cursor does not change like it does for Windows text fields. This is evident throughout PPM and is probably some glitch in the underlying TK control. The Preferences Dialog Major: 1. I had a hard-time exploring this one. THe magnification did no proper tracking and the screen reader's virtual focus was unable to get anything useful out of the dialog. 2. There are some choices about the dialog which I find non-standard. It is resizable and unlike most Windows dialogs provides no roll-back facilities if the user makes a mistake in the dialog. At least there is no Cancel button. 3. The first tab has a list view with radio buttons in it. A radio button is often useless for a binary choice and on the other hand doesn't scale well if you add say more than 10 items. In an equivalent situation most Windows applications use a single-selection list view whose selection tells the preference. On the other hand, that representation can be difficult to spot, too. Cross-platform considerations 1. ActiveState Perl is not a Windows specific product so it would be great to get equivalent access on other platforms, too. I'm by no means an expert user of either MacOS X or Gnome but have tried out the screen readers available namely Voice Over and Gnopernicus. I don't have any hard data but would badly suspect that the TK GUI is as inaccessible on either platform as it is in Windows. To my knowledge, GTK2 is still currently the only accessible major GUI library in Linux, although QT4 will follow. On the Macintosh, the Aqua UI generaly works, where as anything else including MacOS Classic, Carbon and X Window System does not. Well, hope this can be of help. I would appreciate info on usability fixes in subsequent releases. -- With kind regards Veli-Pekka Tätilä ([EMAIL PROTECTED]) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/ _______________________________________________ Perl-Win32-Users mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
