WebbIE 4.2 – response to feedback

I’ve had some great feedback on WebbIE 4 – thank you all. This has resulted in two things:

First, it turns out that the USB stick versions of WebbIE have some strong supporters who use them in various teaching and support environments. I had anticipated the death of versions of WebbIE designed to run solely from a USB stick for what I thought were good reasons:

  • Microsoft Windows has made it increasingly hard to run software from a USB stick. It used to be that you could write some simple code and a program would launch just by inserting the USB drive. Now you’re likely to see nothing at all, and have to navigate to the drive – if you can find it – and launch the program by hand from Windows Explorer. There are excellent security reasons for this downgrading of the experience, but I perceived that it made the USB sticks significantly less usable and hence useful.
  • More generally, corporate and institutional security is getting better, so being able to walk up to a random computer, shove in a USB stick, and run a program off it is surely something of the past.
  • Having people run USB versions means that when a user runs into trouble I can’t be sure that they have the latest, bugfixed, working version. Sure, that’s fine for savvy technophiles. But often people with USB stick versions are the least technical: the system has been set up with the USB stick versions by a friend or support worker. The user has no chance of updating the USB version, and I have no way to trigger an update, even if I can identify that they need one. Very messy.
  • The new rewrite of WebbIE into the .Net programming language means that I can’t guarantee, as I could with Visual Basic, that the programs will run on any Windows machine as a user. You have to be an administrator to install the necessary .Net Framework. So the development of the WebbIE USB versions are stuck at version 3, so it will be increasingly hard to support them.

However, I’ve had various messages from people asking for the USB stick version, and making a reasonable case. They say that they use it for independent access, for (indeed) walking up to machines, especially in libraries and running WebbIE and for distributing easily around organisations. My worries about support are still valid. But if people find it useful, that’s great.

I’ve therefore linked directly to a zip file containing the WebbIE USB stick version on the front page of the website. This is WebbIE 3 and all its associated programs. I hope that’s useful for people.

The second thing is an update to WebbIE, now to 4.2. I’ve done lots of bugfixing, and tried to address the perennial problem of recognising when the page is loaded so it can be processed and the ticking noise turned off. More interestingly, I’ve made some changes again based on user feedback:

  • Print has always been in WebbIE, but I’ve never been quite sure what to print out when the user hits it: the text view, in large print and little decoration, so it can be read by someone with limited vision? Or the web view, so it looks like the web page as seen in Internet Explorer and can be shown to ticket inspectors and filed away as bank statements and the like? In WebbIE 3 I tried to print whatever the current view was, web or text. In WebbIE 4 I decided on printing the text view, but after user feedback it now prints the web view. This lets you get a perfect printed copy of the page for reference. Users can print the main text view by copying and pasting in Word or Wordpad, which saves me having to write code and keeps the number of printing applications down to keep things simple.
  • Favorites or Bookmarks have always been an important feature of WebbIE. These are shared with Internet Explorer. In WebbIE 3 they would appear if you opened the Favorites menu (Alt and A) and you could cursor down them. In WebbIE 4 I created a new “favorites homepage” that shows quick links to main WebbIE functions, like “open a web page” or “search the web”, followed by the favorites. The idea here was that you could just start WebbIE and cursor down to hear your favorites, without having to do an Alt key combination to get a menu up. That’s been very popular with some people, especially novice users. However, people usually expect web browsers to go to their online home page. Also, you can’t type letters to select favorites in a text area, because it isn’t a list: many screenreader users know to start typing the list entry they are looking for and it will be selected, which means they need some sort of list control. I’ve therefore allowed the user to select whether the home page is my favorites WebbIE page, or the Internet Explorer web page. I don’t like adding new options, but this is a generally known and understood one, and there are important different use cases. I’ve also added a new function, Show Favorites, on Control + B (for Bookmarks) that brings up a new window with the favorites in a list (actually a treeview to cope with folders) so a user can press B (in QuickKeys mode) and they cursor or type to get their favourite with ease. I hope the hybrid approach suits most people effectively: new users can use the WebbIE home page, more advanced users can use their familiar page and the bookmarks list.

Finally, a new beta version of R.S.S. News Reader is also up on the site, so do try it out and let me know how you get on! Soon I’ll be able to write new programs again, which will be fun.

Switch to WebbIE 4

I’ve had various reports of problems with users of Windows XP with ASDL modems that WebbIE 3 doesn’t start up. Also, Google search is broken. I’ve seized the opportunity to tell people who’ve mailed me to use the new WebbIE 4 instead, and that’s confirmed to me (after a bit of bugfixing) that it’s working and pretty much there.

I’ve therefore decided to push ahead with the official release of WebbIE 4, and with it the other new .Net-version programs – PDF Reader, BBC iPlayer Radio, and BBC Live Radio. I’ve removed all of these from the WebbIE MSI installer file that used to contain every program. I’ll continue to distribute this so the people can get the remaining programs, until I either convert then to .Net or build separate installers.

The front page of WebbIE therefore lists separate installers for the new .Net programs – WebbIE, PDF Reader, BBC iPlayer Radio and BBC Live Radio – and links to the updated MSI that still contains Podcatcher, Clock, Calendar, and RSS News Reader. I’ve also left the old WebbIE 3 installer still on the page.

A reminder of the advantages of the new .Net programs:

  • Per-user installation (ClickOnce or MSI) with automatic updates. Not having the latest version is the Number 1 reason for mailing me with a support query.
  • Working modern code that will keep working for another eleven years.
  • Better support for screenreaders through MSAA/UIA support.

It’s a bit of a journey, but I think it’s the right direction! Thank to everyone for feedback.

New versions of PDF Reader and BBC iPlayer Radio

As part of the massive WebbIE re-write into .Net, I now have online new versions of PDF Reader and BBC iPlayer Radio. These are pretty much the same as the existing programs, of course. PDF Reader uses a different third-party tool to convert PDFs into text, but otherwise they are the same.

It’s taken me longer than I hoped, not because the programs themselves were too tricky to write, but because I had to change installer mechanism again. I had hoped that ClickOnce would give me what I needed: a simple per-user installation mechanism with built-in update mechanism. Most technical queries I get are resolved by updating to the latest version. But ClickOnce does not allow for handling file extensions (except for a narrow and unhelpful scenario) nor registering as the default browser. That means I had to rewrite the installer for WebbIE, again (it must be able to make itself the default web browser) and use the same techniques for PDF Reader.

So, making progress: RSS News Reader and Podcatcher next since they share so much code. I may have to pause and make per-program installers from the existing single-installer MSI, so that people can still get programs I haven’t moved to .Net if they really want them.

Updates to WebbIE too: you can make WebbIE the default web browser, and password inputs no longer show the passport (just the customary asterices.) Thanks to everyone for their feedback.

New WebbIE Development

Over the last two years I have been working to move the WebbIE programs from the old programming language they have been written in (Visual Basic 6) to the newer .Net. Users of NVDA and Thunder will find that the programs are easier to use and controls are better-labelled. The software will run more smoothly and reliably on modern machines, and be easier for me to manage.

This means that there are now new Beta versions of the new WebbIE 4 Web Browser and the BBC Live Radio program, which you download from here:

This is a significant change: for geeks think “Netscape to Firefox”. I’ve recoded pretty much all of it, which means many features have disappeared – unused ones, I hope – and some new ones have appeared, such as the start of support for accessibility features in HTML5. I’ll keep the old WebbIE installers and code around for anyone who wants them, but new .Net versions of everything will eventually be created.

I have also chosen to change how WebbIE is distributed. Instead of one single installer file, from which you can install whichever program you want, I am moving to different installers for each program. The main benefit of this is that this allows me to use a different installation system that will automatically update everyone when there is a new version: this will be a great help (especially for the BBC iPlayer programs.)

I will also be dropping some of the WebbIE programs, those which I think are least used. My plan is to drop:

  • Disk Explorer
  • Google Podcast and RSS Search
  • Gutenberg
  • I.E. Appearance Editor
  • Web Directory

This will eventually leave us with:

  • WebbIE web browser
  • The BBC programs
  • R.S.S. News Reader
  • PDF Reader
  • Clock
  • Calendar
  • Podcatcher
  • Radio Tuner

However, this depends on my doing a lot of work, so it might end up that more of the programs disappear, or are never updated. Which is fine if the old versions keep work: I’ll just split them out as separate installers for anyone who needs them.

So, please do try out the new Beta of WebbIE 4 and let me know of any problems or comments. Next time, details of what’s new in WebbIE 4.

Guidelines for building accessible video games

Gamers with a disability often lack support in popular video games. If you’re a gamer designer you may not be able to address every potential user, but if you know how to make things easier or more playable then you may be able to implement features in a way that expands the number of people who can use your game.

A great set of guidelines has now been brought together here: Game Accessibility Guidelines. For reference, here are the basic guidelines – they are covered in detail on the site.

General
Provide details of accessibility features on packaging and/or website
Offer a choice of difficulty level
Ensure that all settings are saved/remembered
Motor (Control / mobility)
Allow controls to be remapped / reconfigured
Ensure that all areas of the user interface can be accessed using the same input method as the gameplay
Include an option to adjust the sensitivity of controls
Ensure controls are as simple as possible, or provide a simpler alternative
Cognitive (Thought / memory / processing information)
Allow the game to be started without the need to navigate through multiple levels of menus
Use an easily readable default font size
Use simple clear language
Use simple clear text formatting
Include tutorials
Visual
Ensure no essential information is conveyed by a colour alone, reinforce with a symbol or offer a choice of alternative colours
If the game uses field of view (3D engine only), set an appropriate default for expected viewing environment (eg. 60 degrees for TV, 90 degrees for monitor)
Use an easily readable default font size
Use simple clear text formatting
Provide high contrast between text and background
Hearing
Provide separate volume controls or mutes for effects, speech and background / music
Ensure no essential information is conveyed by audio alone, reinforce with text / visuals
If any subtitles / captions are used, use an easily readable default font size, simple clear text formatting and provide high contrast between text and background
Speech
Ensure that speech input is not required, and included only as a supplementary / alternative input method

ChromeVox browser extension

ChromeVox is a self-voicing browser extension (add-in) for Google’s Chrome browser. It’s designed by T.V. Ramen, the guy behind emacspeak.

It’s optimised for Chrome OS, at present (Google’s operating system that basically just gives you the Chrome browser as your desktop), probably because it is the only plausible accessibility story on Chrome OS for blind people, but it works fine on other systems.

You get a bunch of hotkeys that let you navigate around the page and a synthesized speech voice. The functionality is pretty geeky: if you’re comfortable with the idea that a web page is a hierarchical arrangement of nodes of different types, then you’ll fit right in. However, if you’ve already learned your many hotkeys for your screenreader to use Firefox or Internet Explorer, then you’re probably not going to find anything more useful in ChromeVox.

It’s maybe most interesting for Thunder Screenreader users, who can use ChromeVox with Chrome to give them the advanced geeky webpage navigation features previously enjoyed by JAWS or NVDA users, but can still fall back on the simpler Thunder features in Microsoft Office or WebbIE – and all for zero cost, since both Thunder and ChromeVox are free.

Keyboard traps and Javascript’s preventDefault

Nomensa has a good article on their blog about Keyboard Traps, or “I don’t use a mouse and the Javascript on a web page is stopping me tabbing past an item.”

Here’s the theory. If you use Javascript events and code to override the normal keyboard operation on something like a link or button then you have to check that you can still use the page with the tab, return, space and cursor keys. If you’ve blocked this, for whatever reason, your page will no longer be usable/accessible for keyboard users – screenreader or switch users, for example.

The example given in the Nomensa article, however, is an odd one. It traps not clicks but keyboard activity. So it’s a link that would open a pop-up window if you pressed a key while it had focus, and uses the Javascript preventDefault statement to terminate the key activity, blocking the tab to get to a new link.

But mouse users would not see any effect. This means it’s unlikely that this scenario will ever be coded: mouse users are generally the target audience, so the scenario is usually going to be “clicks are trapped and do something different” not “keyboard activity is trapped and does something different.”

Here’s an example: the Firefox development test for preventDefault. You can activate the blocking of normal mouse operation on the test checkbox, so you can no longer click on it to check or uncheck it. But using a keyboard you can tab past it and even check it! The development test assumes you trap the mouse click event, not keyboard events.

This suggests that the accessibility problem with preventDefault won’t usually be the creation of keyboard traps.

The accessibility problem preventDefault is that it will be used to create webpages where a keyboard user gets different functionality from a mouse user.

Most likely, this means that webpages that use preventDefault in trapped click events won’t work properly for keyboard users – for example, when you activate a link with the keyboard instead of the mouse, then instead of operating some code somewhere on the page to make a hidden piece of text visible, you trigger a navigation action.

And look, here’s an example of exactly that problem from stackoverflow: preventDefault() on an <a> tag Mouse users get to see text appear and disappear as they click. Keyboard users just get a click as the browser navigates to the page again.

What to recommend? If you must use events and preventDefault then trap both mouse and keyboard events, but make sure you don’t trap tab or cursor key presses or you’ll break keyboard users.

But better still, don’t use Javascript to break the default activity of a webpage element. If you want something you click and does something use a button, not a link!

Alt Tag HTML Tip: If you swap out your image, does the text still work?

If you’re a good web designer (or just one who cares about his Google ranking) then you’re populating your IMG elements with the alt attribute (tag). Sometimes this is easy, like when you’re describing a picture in a new story. Sometimes, however, you’re using an IMG element because you’re overcoming some stylistic problem with using plain text – in other words, you’re using an IMG for text content. A good example is on the BBC News website. Here’s the (edited) code:

<a href="http://www.bbc.co.uk"><span>British Broadcasting Corporation</span>
<img src="light.png" alt="BBC" /><span>Home</span></a>

If you’re sighted you’ll observe on the actual page that you see none of the words “British Broadcast Corporation” or “Home”, just the BBC logo as an image in the top left, and as normal you can click on it to go to the BBC home page, so it looks neat and simple. What’s the extra text for? We can surmise that if you’re using a screenreader or other AT device you might, depending on the AT, hear “British Broadcasting Corporation BBC Home”, which may be more helpful than just “BBC”. Let’s assume that’s the idea.

The problem is that in the absence of any visual positioning, and without any CSS instructions to add  spaces into the code, what you’ve actually coded when the IMG element is directly replaced by its alt attribute is this:

<a href="http://www.bbc.co.uk">
British Broadcasting CorporationBBCHome</a>

If you run that into a speech synthesizer you’ll probably hear something like “Broadcasting Corporation-buh-buh-chome”, which isn’t what you wanted!

The problem is that there aren’t any spaces in the text that results from swapping out your IMG element with its alt attribute content. Sure, the AT could guess that you wanted to have spaces, but then it’s changing your content – and you’ll quickly run into a situation where adding spaces in breaks up other words when it shouldn’t, like sites that use IMG elements to produce fancy initial letters on the first words in paragraphs. What you should do is something like this:

<a href="http://www.bbc.co.uk"><span>British Broadcasting Corporation </span>
<img src="light.png" alt="BBC" />
<span> Home</span></a>

or this:

<a href="http://www.bbc.co.uk"><span>British Broadcasting Corporation</span>
<img src="light.png" alt=" BBC " />
<span>Home</span></a>

In other words, structure your alt attributes so that your content still makes sense when the IMG element is replaced by the alt attribute content. Simple, but easy to overlook.

Microsoft UI Accessibility Checker 2.0

I’ve been doing some application building in the last few days, and I’ve found Microsoft’s (newish) free AccChecker program enormously helpful.

In some ways it’s much like the old MSAA tools AccExplorer32.exe and inspect32.exe. You can navigate around the MSAA tree for a program/window, explore what controls work and what don’t, and check you or your GUI toolkit have correctly populated the necessary accessibility information. Because Microsoft is trying to push us all to using UI Automation instead of MSAA it also provides you with the full range of the richer UIA content.

This’ll be especially useful as we try to support things like text rendered using DirectDraw/DirectX in Internet Explorer 9 (breaking lots of offscreen models). But in any case it’s an enormously useful utility. It’ll check tab order, screenreader views, UIA errors and even provide you with priorities and commentary on problems. Finally, the code is available from CodePlex to demonstrate the UIA techniques involved: great for anyone writing UIA support for AT or scripting.

Download AccChecker 2.0, June 2010

Windows 7 UI structure and shortcut keys for screenreader and switch users

Many people using assistive technology have to learn ways of doing things quite different from the “see, move mouse, click” paradigm most users can employ. For (blind) screenreader users it’s vital to know shortcut keys, and for both screenreader and (physically-impaired) switch users a good knowledge of the structure of common Windows user interface artifacts, like Explorer or the Start menu, is enormously important for getting the most out of their system.

Microsoft has provided “A Guide to Transitioning to Windows 7”, a Word document that provides a detailed examination of the Windows operating system user interface for people not using a screen and/or mouse. For example, it describes how to interact with the Ribbon interface used in Office 2007 and 2010 and now in applications like Paint.

It will be of use to high-level screenreader and switch users and user interface and AT developers who want to know how things (are supposed to) work for AT users.