Defining Keyboard Access

Back in May I attended a Becta event which launched their"Making Software Accessible" guide. I also wrote a blog entry that covered the Becta event.

I was pleased to see David Colven from the Ace Centre presenting. David brought along some short video clips that illustrated the need for single key access for some applications.

These videos left quite an impression on me as they illustrate so very well how important technology has become to overcoming physical impairment, and how easy we can miss things if we don't take a holistic view. It's easy for us sometimes to limit our concept of "access" to filling out an online form or navigating a web page, but these activities only represent part of what we can achieve with our computers.

The videos feature Peter Harris. He was 14 at the time these videos were taken. Peter wanted to draw, and In the first video he has been given a drawing package and a mouse to try:



In the video, you can see how Peter struggled with the mouse interface. He produces a picture, but it's not what he had intended. So the guys at the Ace Centre looked to keyboard control to overcome Peter's Athetosis.

The next video shows Peter using a specially adapted keyboard that has a mask that helps to prevent multiple keys being pressed accidentally. But Peter's posture suffers because of the position he needs to be in to be able to press 2 keys simultaneously:



Again, the results aren't what Peter had hoped for.

In this last clip, the guys at Ace modify the package so that it can be used with just a single key press. Basically it's space to start a line, arrow keys to move, and space again to finish.



You can immediately see that the results are much better. Peter lived on a farm and really enjoyed farm machinery. With a little patience, Peter was able to produce the following drawing of a Landrover:

When I saw this on the screen I was amazed. Having seen what Peter had produced previously, I did not expect him to be able to draw like this. But Peter's results where limited not by his own ability, but by the limitations and inflexibility of the tools he previously had access to. In response to Peter's specific needs, the practitioners at the Ace Centre provided him with a method to produce this wonderful drawing.

Summary:
People's experience with disability differs a great deal. I'm quite privileged in being able to work so closely with the team at the Shaw Trust as part of my job, but even so, these videos really opened my eyes to the way we as a community tend to think of disability and technology. Particularly:

1. We're often guilty of categorising disability in our approach to accessible services in using terms such as "keyboard accessible" without truly considering the different modes of operation.


2. We often limit our idea of access to standard applications, web pages etc. We need to give more thought to improving enjoyment of life through technology. A new approach can lead to someone discovering in themselves a new skill and enhance their lives.


3. Giving people access is not the same as providing people with an equal experience. It's the latter that we need to focus on.


4. On the web, there's too much emphasis on the limitations of User Agents. Yes, it's an important aspect that needs to be considered, but If the guys at the Ace Centre thought "Oh, this package doesn't offer single key operation. What a shame." Then maybe nobody would have found out that Peter could draw.

I'd like to thank David, Peter and the Ace Centre team first for introducing me to these videos and allowing me to use them on this blog.

The software that Peter is using was developed by the Ace Centre. It's called AccessMaths 4.2 and, as the name suggests was actually designed for teaching Mathematics.

WCAG Samurai Errata released

The WCAG Samurai are a mysterious team of web accessibility warriors (mysterious because nobody is supposed to know who they are) led by Joe Clark. The purpose of this secret group was to write an Errata for WCAG 1.0; the oft quoted, but well worn guidelines for web accessibility that have been around since 1999. Joe's contention is that there is no need for WCAG 2.0, largely because the whole process has been dominated by industry and that with a few tweaks here and there, WCAG 1.0 + Samurai is all that is needed to assure accessibility.

Well the first draft of the WCAG Samurai Errata is here.

The process of developing the Samurai errata has been going on over the past year and the draft errata were released at last week's @media event in London.

The Review
There are already a number of reviews popping up as people have found the time to read and review. There were two peer reviews requested by the Samurai:

By Gian Sampson-Wild
By Alastair Campbell

A few more can be found by:

Steve Green
Mel Pedley
Joe Dolson
It only matter is you care
Roger Johansson

...and I'm sure that a few others are being written at this very moment.

The reviewers tend to agree on most things, particularly the overly optimistic dependence on User Agents to get it right (when we know they don't). This is a big problem throughout the Errata as the only people that will lose out because of this poor postulation are the very people that it is designed to help.

Counter productive?

On the whole though, the document is pretty good as it contains some very detailed and practical advice on the treatment of video and audio content. These parts alone make the document a worthwhile read, and I hope that the guys behind WCAG 2.0 are paying attention.

Now while Joe has been quite vocal about WAI and WCAG 2.0, I can't help thinking that there's a little too much WAI bashing in the document itself. Some of the info is useful, but has a deliberate contrary tone. While this makes for good reading, it's not so good for a standards-type document. It tends to leave me wondering whether parts of it are simply based on good practice, or whether it's just a snipe at someone. Additionally, there is an overly sympathetic tone used towards PDF production which probably sprouts from Joe's personal involvement with the PDF/UA Universal Accessibility Committee

There's also a blanket bombing of Priority 3 requirements, which as Steve Green points out in his review includes Checkpoint 2.2:

2.2 Ensure that foreground and background color
combinations provide sufficient contrast when viewed by someone having color
deficits or when viewed on a black and white screen. [Priority 2 for
images, Priority 3 for text].

And also includes the abolition of access keys, something, that I've been fighting hard against based on the fact that I work with people who find access keys useful (a discussion for another time). But the point here is that the errata are very black and white (deliberately) but some shades of grey need to be thought about more carefully.

There are lots of other things I don't agree with, most of which have already been pointed out by others but there is one item though that sticks out as a really, really bad piece of advice:

Do not cause pop-ups or other windows to
appear and do not change the current window without informing the user. (Plain
text is the preferred method of informing the user. The title attribute on a
hyperlink a element can suffice.)

A couple of things,

1. The title attribute should NEVER be relied upon to convey any information. EVER


2. "Plain text" rather than "The link text itself" is no-where near enough to inform a user that a link is about to open in a new window.

Steve Faulkner, comprehensively covers the issue in his presentation "The Title attribute - what is it good for?"

I'm surprised that Joe et al feel that title is an adequate device, or perhaps it is seen as a UA issue (which it is not, the issue is far more complex and involves many different considerations including work flow, usability, and modes of activation - a topic for another time maybe).

Political impetus
There's a bit of a space race on at the moment, the community is waiting for a set of workable standards that before the last draft, WCAG 2.0 looked like it was going to fail to deliver, since then, WCAG 2.0 has had a fairly positive reception, although it still has a way to go, it seems to be at least heading back in the right direction. I'm sure that both parties are keen to get their documents out first. I do believe that it's unlikely that the Samurai Errata will get much attention if a workable WCAG 2.0 is released ahead of it. Apart from a few die hard fans, I can't imagine many sites sporting a WCAG + Samurai logo. So early adoption at this stage seems to be the errata's best hope.

Conclusion
I'm glad that the Samurai's errata has been written, It provides a lot of very useful information that can't be had via WCAG 2.0. The style of writing is refreshing and it's an alternative to WCAG 2.0. I'd encourage those that are new to accessibility to read it as it contains so much useful advice, I'd go as far as to say that it will probably help me to form a clearer opinion on some things, particularly where sound and video are concerned, although I'd also feel inclined to point out that the tone of the document is a little political and opinionated and therefore needs to be read with some caution.

An Introduction to Screen Readers - by Victor Tsaran

Victor Tsaran, an active GAWDS member working for Yahoo! talks us through how he uses a screen-reader. For those that are new to accessibility, a screen reader is software that helps a visually impaired computer user gain access to screen content. It works by reading the content and controls available on the page back to the user. Hmmm, I'll let Victor explain it...



I've also just recieved some video from David Colven at Ace Centre It shows Peter Harris, one of the centre's clients, doing some very impressive drawings using single key presses. I mentioned this in my blog a couple of weeks ago. I'll put it up as soon as I've had a chance to 'youtube' it.

What's missing from WCAG 2.0?

A short time ago, Jack Pickard published an excellent review of WCAG 2.0 on Accessites. Although I hadn't had a chance to read the whole of the WCAG 2.0 document myself, I was pleased to see that the guidelines had made such progress. This morning, as I was reading the guidelines I realised that something was missing. A piece of guidance that would enhance the web experience for many disabled web users just wasn't there.

Now not everyone will agree with my observation, and say that it is the responsibility of browser developers to cater for this need, but I know for a fact that if there is no guidance on this area of accessibility then lots of people are going to lose out.

Now you see it, Now you don't

Back in January, I wrote about the importance of link highlighting, a simple feature that takes seconds to implement, requires little or no design skill and just an ounce of development skill.

Now while I wholeheartedly agree that it is the responsibility of the user agent to provide the highlighting mechanism for links and form controls (something customisable would be ideal), the current default mechanism (a feint dotted outline) can be very difficult to see and will require some time to track down. I know this because I have sat next to people that have completely lost track of where the focus area is and have resorted to trying to make sense out of the link information in the status bar, sometimes with no success. Once the focus is lost, it can be very hard to find it again, even with copious amounts of tabbing.


(This example from the BBC homepage is the best I can come up with at short notice, I'll replace it as soon as I get something better and that doesn't incriminate one of my clients. But How long does it take to you to figure out where the focus is?)

Was WCAG 1.0 more user-centred?

WCAG 1.0 provided some checkpoints that, let's face it, are pretty useless now, but at the time probably saved the sanity of thousands of web users, Checkpoint 10.4 for instance tells us to populate our form fields with some content. It seems like an odd requirement now, but it was critical for many disabled web users back in 1999 when early screen readers would ignore form fields if they did not have something in them, (or so I am told). WCAG 2.0 currently seems to assume that user agents (browsers and assistive technologies) need no further improvement, or at least that developers shouldn't worry about their known shortcomings.

I don't want to go into this area of debate about whether developers should make up for browser inadequacy really. You'll need to form your own opinion on that. What I do know is that a simple fix can transform the experience for many users. I also know that a soft approach by WAI in the past (Until user agents...) has resulted in a better standard of browsing for many disabled web users.

Maybe the same soft approach would do the same to help many more people now. Isn't that what WAI is about?

Making software accessible: rising to the challenge

Last Thursday (17/05/2007) I attended the Becta event "Making software accessible: rising to the challenge", with Andrew Evans, our Standards and Interoperability Specialist.

I have to say that the event was quite an eye-opener. I was struck by the emphasis on cognitive and learning disabilities which have such a bearing on education. It should be obvious that these are a prime concern for many educators and it seems silly now that I was surprised by it. I suppose I've been so focussed on the physical aspects of accessibility on the web that I hadn't considered the shift in emphasis when it comes to education.

Another issue was the need for teachers to be able to use the online material in different forms - extracting images, or cutting and pasting text for use in other documents. This is partly because some students respond better to physical resources, but also because many students aren't able to interact with certain pieces of software because they aren't keyboard or screen reader accessible. This is another thing I was shocked by. It's hard to believe that in 2007 vendors are still selling products to schools which can only be accessed via mouse control. Many of these vendors have been around for a decade or more, but for reasons I can only marvel at, haven't factored disability as a concern.

There was a great video demonstration by David Colvern of Ace Centres which showed a mobility impaired boy using a simple paint package. His impairment meant that he could only use one key at a time to draw a picture on the screen. He had to move the cursor, start drawing a line, end drawing a line, change colour etc. all with single key presses. The fruits of his efforts were astonishing, and if it hadn't been for a simple customisation of the package by the guys at the Ace centre then maybe nobody would ever have known that he could draw at all. I'll try and get permission to post a copy of the finished image to show here.

There were some very good presentations on the day, but Carol Allen, a respected practitioner from North Tyneside made a statement that summed the day up for me. She said:

Give me FLEXIBILITY!

...and for me that's the new challenge, helping Accessibility, Usability and Flexibility play together.

Why we use headings

There’s been a lot of debate about headings lately on the GAWDS mailing list and at the recent PSF event. I think this is great because it means that people are discussing the finer points of accessibility and working on the details.
I thought I'd repost my response on the GAWDS list here for those who don't use the GAWDS mailing list (shame on you!).

The problem with headings is that nobody seems to be able to agree on which heading needs to start the page, and whether it’s OK to skip a heading or not. The problem is further compounded by automated tools which will fail you if you use more than one H1 or if you skip a heading element (say H2 to H4).

I need to make it clear that I'm not advocating sloppy structure, sites should be designed with a logical heirarchy as part of good design practice.

I’ve put something together here to try and illustrate how JAWS users use headings and why these main concerns may or may not actually be that important from a practical perspective. So if you've inherited a site or these changes are out of your control you'll be able to have a better idea of their impact.

How Screen Reader users use headings

Here are some examples (for those that haven't had the opportunity to use a screen reader like JAWS):
By pressing "H" on the keyboard, the user can cycle through headings. JAWS will announce the status of each heading as it appears in the cycle e.g. "heading level 1 company name", so in this way, the user gets an indication of the order of the headings as they appear on the page and what heading level they have been given (we'll come back to that in a minute).

Another way is by bringing up the heading list dialogue (insert + f6 in JAWS), which displays a list of all the headings on the page. The user can cycle through the headings using the up and down keys, the level of each heading is also announced in this dialogue. The dialogue has controls so that the user can sort headings by alphabetical order or tab order and also only to list headings at each level. I've personally never seen these dialogues used, but different users will have different methods, and I don't spend as much time with these guys as I would like.

So in terms of what the user expects to see as a H1 or H2 is highly dependent on whether they've visited the site before as each site has a slightly different approach to how headings are used (I doubt that this will ever change) so I think the most important thing is consistency.

Consistency is the key

If you're using H1 for your site logo, article heading or navigation heading, then you need to keep using that on every page of the site. If you find yourself in the position where you don't have a logical H3 for the page, but you've consistently implemented H4 for your section headings then in my view (and I'm sure others will disagree) you should keep on using the H4. Don't feel inclined to change it to a H3 just for that page just because you don't want to skip a heading level or to pass through some automated accessibility testing robot.

This is important because if you happen to have a lot of headings on the page and typically the user is looking for a certain H4, they could assume that this new page doesn't have the information they are looking for because it has been changed to H3.

There is a counter-argument to this because if you have a H2 and no H3, you may assume that the user won't look for a H4. But this is a weak hypothesis, because if the user is using the "H" key as described above, they will happen across the next headings whether it be a H3 or a H4. If they are using the headings dialogue, the same is true. If they are using the dialogue to list the H3s only and find nothing, this is also fine, because they will be looking for the H3 equivalent of what they found on another page. If there is not one, then it is logical that none are present.

I think the debate is useful and interesting in that a consensus will bring greater consistency across the web, but developers shouldn't mistake this as being a critical issue, the key (in my opinion) is to use lots of headings (as long as they are relevant) and use them consistently across all pages. And I'm aware that what I've stated may not quite be in accordance with W3C specifications (I'm not sure), but works best from a practical perspective.

I hope someone finds some of this useful.
If you're a screen reader user, I'd love to hear from you.

PSF accessibility gathering

Public Sector Forums (PSF) made my week by facilitating a presentation where I got to present along side some of my favorite accessibility names. Bruce Lawson, Patrick Lauke, Anne McMeekin, Ian Lloyd, and Dan Champion, (who organised the event for PSF). The event took place in the function suite of Edgbaston cricket grounds yesterday.

The event seems to have been a big success with "exemplary" speaker feedback. A big plus for me was getting to spend some time with some really interesting people.

If you're interested in seeing them, Patrick took some photos of the event and the preceding night out.