Accessibility Training

Wow, what a busy week. Today we had the first day of an internal conference at Yahoo! about Front-end engineering or as they say in internal acroynization F2E.

There are two things that I notice in particular:

1. We have so many really really smart people at Y!
2. We are in a great position to offer accessibility training

While the first point may seem a little like propaganda, I really don’t mean it to be. I’m always very proud of our European team, with people like Heillman and Drew to just skim the surface. However, being in the crazy Yahoo! land that is the Sunnyvale campus I was blown away time after time by the people I met.

The YUI Team are a bit obvious, but people like Scott Schiller and Philip Tellis and many others are also a joy to spend time with. We had dinner last night with a new Yahoo! and it was interesting to see him be a little shell shocked by the general knowledge people displayed at the table. You guys are really scary, you know that?, he said after a discussion about JSON security. Half a year ago I would have said the same thing, now it’s starting to become normal.

The second point refers to the high quality of talks at the conference this week. One of the main themes was accessibility, and there is some great material being presented. I particularly enjoyed seeing Victor Tsaran‘s work with the YUI Team. I hope to see more stuff like this, and open up as much of our accessibility material to the community as we can.

So, Yahoo! really has the best web front-end developers in the world. I’m so pleased to be here. I guess my brainwashing is complete, but hey, may my blood run purple.

Technorati Tags:
Web Development, Accessibility, training, yahoo, scottschiller, philiptellis, victortsaran, chrisheillman, drewmcclellan

Web Standards Group London – Accessiblity

Since I know there is going to be a podcast I’m just going to highlight a couple of points from the London Web Standards Group Meeting I thought were interesting to me.

I’m glad Niqui talked about FlashAid. Aral and Jeremy did a fabulous job. I posted some comments on how I would like to see Flash Aid used already, but I look forward to seeing what the community thinks.

Mike Davies talked about an example where an application he consulted on had one double quote that stopped the application from working on Firefox. This is a great example of why web standards are important. With it’s growing market share something as simple as missing double quote mark probably cost a significant amount of money.

The other point I took away from Mike was that imagination is one of the greatest tools in the accessibility toolbox. As soon as you start empathising with people with disabilities you start to be able to make sensible guesses at what they would find hard on your site. If you can’t navigate your site with the keyboard, chances are other people can’t either. Mike has really hit the nail on the head with this one.

However Ann McMeekin also made an excellent point which counterbalances the previous one. Assumptions about the way people with disabilities need a site to be can also lead to some real howlers. There are communities of experts out there to help you. If you think there is a problem but aren’t sure, find someone who really knows. The RNIB have some great resources for such things, as do a number of other sites. You can even email me at tom_croucher@yahoo.com if you like.

All in all a great session. Well done Niqui, Ann and Mike! And well done Big Stu for organising another great session.

Technorati Tags:
Web Development, Accessibility, londonevents

It’s not graceful or enhancing this progression is just degrading

So I have a problem. It’s a bit of a corker, and it seems like everyone who uses AJAX suffers from it. That means, me, and probably you.

The problem is AJAX is not accessible. Gez and Steve improved the situation, but again AJAX is not accessible. I know I’m being rather alarmist, but the situation is starting to eat at me.

Right now, we have a solution which works for JAWS 7.1 and for the latest version of Windows Eyes. But what about users using screen readers older than that? The problem is the massive amounts of mixed messages and myth.

1. Most blind people use JAWS
2. Progressive enhancement / Graceful Degradation will protect users from functionality they can’t use
3. We can’t be expected to support all versions of user agents

1. Most blind people use JAWS

We have a solution for JAWS. Yet, there are no published figures with any authority I have ever seen that show percentages of users that use which screen readers. It is largely, and informally, accepted that Freedom Scientific are the leading vendor. However, Windows Eyes and Hal are not to be discounted as well as the other readers around on the market.

2. Progressive enhancement / Graceful Degradation will protect users from functionality they can’t use

Many version of screen readers now support JavaScript. A lot of screen readers are based on the MSAA using Internet Explorer. In order to access non interactive elements of the page to interact with they have to implement a “virtual buffer”. The problem? The javascript is being supported by the browser, so the progressive enhancement is progressing and the graceful degradation isn’t degrading. The problem, is in fact, that the virtual buffer isn’t refreshing and the user doesn’t know.

3. We can’t be expected to support all versions of user agents

Most user agents are free. Assistive technology isn’t. In fact, assistive technology is pretty expensive, as much as a new computer. More than that, it is well established that people with disabilities tend to have significantly lower incomes than the national average. That does sound like constant upgrades might be an issue.

So where do we draw the line? At what point does a browser become un-supportable? Well the main issue is that our normal techniques for excluding a browser based on functionality doesn’t work. This combined with the unusual economics of Assistive Technology mean a new selecting the bottom line must be found. A little research shows that there have been 7 versions of JAWS and 4 version of Windows Eyes since 2001. However finding quality information on the capabilities of screen readers is hard without actually having them.

Solutions?

The ideal solution would support all assistive technology which can run JavaScript. That minimum level would allow the progressive/graceful enhancement/degredation to kick in. The problem is I don’t have a solution. What I really need right now is lots and lots of screen readers. I have access to the latest version of JAWS, and Windows Eyes. I need access to anything else I can get my mitts on in all versions possible. If you can help please contact me.

In terms of raw ideas, the best I have right now is to use Flash to detect MSAA support and disable the AJAX. For JAWS it may be possible to use an Active X component (remember until JAWS 7.0 only Internet Explorer was supported) to hotwire older versions using JAWS scripting. But that’s about it, and it ain’t a whole lot.

Technorati Tags:
AJAX, Domscripting, Javascript, IE, Web Development, Accessibility, Screen Readers, JAWS, Windows Eyes

Accessibility training

I’m writing some accessibility training for us to use at Yahoo!, and I’m wondering if people have had some great training in they would like to share ideas about. What kinds of things made training really work for you? Is there any material that I should look at if I am writing training?

Company permitting I would also like to make some of our training material pubic. So, what things do you think are missing from the ranks of accessibility training? What would you like to see that we might be able to rustle up for you?

Please let me know and I’ll do my best to work in suggestions and create things to fit your needs.

Technorati Tags:
Web Development, Accessibility, training

Escape from the JAWS of inaccessibility

I really loved Gez and Steve’s original post on AJAX and JAWS, they have just added an update that covers methods to force updates to the JAWS virtual buffer.

This information is invaluable as it allows developers to write AJAX application which work in the audio rendering mode which most JAWS users use. My current fears about the use of Javascript, are the disparity between screen readers (and other assistive technology) and regular user agents, and web developer knowledge of the additions people with disabilities need within their scripts.

To look at the first issue, Steve and Gez have shown that screen readers may work with Javascript slightly differently to other user agents. Event may not behave in the way which a developer imagines. The obvious and now documented example is that of the non-refreshing DOM. However, I would not be suprised if there are more examples. This leads me to my second point.

Developers are not assistive technology experts. Asking them to test their code in assistive technology will just lead to false conclusions. Instead what we need is quality information which explains how assisitve technology works on a theoretical level, and then how is functions in practice. Through these explanations and expirement a body of work can be built up to give developers the tools to build for assistive technology without having to test for themselves. We come back to accessibility patterns.

In order to help developers understand they need to use events which work with keyboards, in order to help them understand when they need to focus on dynamically updated content, we need some patterns. Developers shouldn’t and can’t be expected to understand assitive technology, but they do love simple and easy to apply best practices they can apply to their own programming challenges.

Technorati Tags:
Web Development, Accessibility, Screen Readers, Accessibility Patterns, Gez Lemon, Steve Faulkner

Good form, chaps!

I would like to commend the efforts of those involved in FormCamp. I love this idea, that the community can get together and focus on a very specific goal to achieve a useful deliverable. Conferences are great but I like the idea that this unconference actually ends with something which will actively help the community. Ideas and talk are also useful, but this is going to be something solid, something I could use tomorrow!

By Mike’s report it looks like there is an exception group working on this. So I’m really waiting with bated breath to see the output. If this proves a success expect to see more such event. If no-one else yours truly will organise one.

Technorati Tags:
Web Development, unconference, formcamp, accessibility

Inaccessible web site? It may not be entirely your fault

I was reading through some posts of the excellent Joe Dolson. This one particularly struck me, “What’s the key to Accessibility?“. In it Joe says:

In a word, options. Building an accessible website doesn’t mean building a visual experience which will work perfectly for all audience. It doesn’t mean writing content that everybody will be able to read equally. What it means is creating an experience where users can alter their experience as they choose so they can best experience the site.

I couldn’t agree with this more, and Joe phrases it very well. However I have to disagree with what he wrote about implementation. Jared Smith from WebAIM talks about this in the comments saying In nearly all of the testing that we have done on accessibility widgets and options, the resounding response has been that people with disabilities don’t like or even use them. I can well believe this, since with all the good intentions in the world there are no ‘standard’ accessibility widgets. Which means using widgets is just another non-standard thing to learn.

The message I think this discussion brings out is that, there is that web development is a combinations of things to make an experience. Part of that is the web site, but part of it is also the user agent. For a while now web developers have been working to WCAG 1.0 but feeling rotten about the fact that their efforts can fall short of the mark. I don’t like it, but I think the solution is not good intention and clever web widgets. The solution is mature user agents for people with a range of needs.

To go back to my post from a few days ago, we can transform information (especially in a text form) to be rendered in a way that works for someone with any physical disability, we can provide interfaces that work with almost any level of control. However the web development community needs to find their place in this and realise it is not there to solve all the problems. Web development is about presenting the information in such a way that it can be manipulated for rendering on any device, and interacted with by any control. We aren’t here to make all the rendering or devise all the controls. We are the facilitators.

So, if web development reaches the point of offering semantic manipulatable content, what is missing? What’s missing the user agent support to work with the semantic content. While a lot of assistive technology is made by smaller companies, it is still frustrating they don’t fully support standards. If I were feeling cynical I might suggest that assistive technology vendors that sell software to read web sites rely on the poor quality of code for their market edge. To my knowledge there are no UAAG conforming user agents. Why not? It is because there is no driving factors to encourage UAAG compliance.

A standard like UAAG would require additional work, costing the vendor money. What is needed is either a stick or a carrot, in way of encouragement. If an governmental organisation like the DRC were to mandate that all user agents need to conform to UAAG (or be a part of a UAAG compliant package) to sell in the United Kingdom it would have a profound affect on the market. We don’t allow people to make ineffective wheelchairs, why would we allow them to make ineffective user agents? In a similar way, if a large organisation like the NHS offered to buy exclusively from the first vendor to make a UAAG compliant product the market would also change dramatically as vendors scrambled to get the big sale.

It’s not just the user agent vendors that seem to have been unaffected by the increasing drive for accessibility. Web development tool vendors have yet to produce anything which complies with the ATAG. While Adobe/Macromedia applications like Dreamweaver have been making inroads towards more semantic and accessible markup, Apple have released tools like iWeb which is as bad a frontpage ever was. Yet another area that needs a stick and a carrot.

Really what I hope this article has emphasised is the need for web developers to realise that the web site is only one part of a bigger picture to deliver information to the user. I also hope I have raised some questions about why User Agents and Web Development tool manufacturers have been exempted from the legislation which is in place to enforce the accessibility of the web.

Technorati Tags:
Browsers, Web Development, Accessibility, Screen Readers, WCAG, ATAG, UAAG

Accessibility patterns

I was talking with Steve this afternoon, and he put into words some of the stuff I have been thinking about recently.

One of the dangers for developers trying to make things more accessible is believing they understand assistive technology in the way a user does. Unless you use assistive technology everyday you don’t really know what it’s like and even then there is a lot of user preference.

I was talking about how we need to focus on ways to help developers understand how screen readers work without trying to actively use them. To apply ways of working based on understanding the technology and the archetypes of behaviour. Steve pointed out that these were accessibility patterns.

I love this idea. It’s classic software engineering, but it fits so well. A pattern is a solution to a problem space, rather than a specific problem. That works really well with accessibility where one size definitely doesn’t fit all. Talking patterns also gives us anti-patterns. These are known bad solutions to a problem space, something to be avoided.

What this means in practice is we can give developers ways to work which fit a defined set of problems, and ways not to work which we know cause problems. However the developers don’t need to know more than the problem space in order to apply the solution. They don’t need to check with assistive technology themselves to validate (sites always need usability testing with assitive technology by real users still!).

Keep an eye on this space for some accessibility patterns in the near future.

Technorati Tags:
Web Development, Accessibility, Screen Readers

Accessibility; Ever changing; Always the same

It’s been a couple of years since I last worked on WCAG 2.0. However, being at the RNIB today for a demo of assistive technology made me think a lot.

Web accessibility hasn’t changed, some of the techniques have, but really it’s the same old problems that were bouncing around a couple of years ago or more. Web accessibility is still the combined experience of a user agent and a web page. If either of those two let the side down, then one of them has to fill the breech, or the user gets a let down.

I’m still not impressed with the innovation of manufactures like Freedom Scientific, Dolphin and Windows Eyes. I know they are smaller companies but they just don’t to be improving the offerings in the market place, just slowly shifting to keep filtering out the dross of the web for their users. I just don’t think it’s good enough.

Cognitive disabilities were also talked about. It’s a shame really, because they are the forgotten child of the Accessilibity world. Not through malice or sloth, but because they are the hardest to cater for. To badly paraphrase a point I think Joe Clark made.

It’s possible to cater for people who are deaf and blind or motor impaired. Those people all understand the information and you just need to transform it from one medium to another. How do we cope when the person needs very different information.

Update: Joe points me to a much more eloquent explanation (see last paragraph of his comment).

It’s not that we don’t care, but do we let our complete inability to sensibly deal with cognitive disabilities affect our work for everyone else? It’s the worst choices in pragmatism, we don’t want to leave anyone behind, but you have to start somewhere. Perfection on the other side of the mountain, but I make a start by climbing the foothills.

Possibly I’m being contentious but I guess it comes from looking at the same problem two years on and hearing the same arguments from different mouths.

Technorati Tags:
Web Development, Accessibility, Screen Readers, JAWS, Windows Eyes, WCAG

RFID Ears

It often occurs to me that people try to do too much with new technology, and that maybe if they thought a little more simply they would get better results. RFID tags are a point in case. The number of justifications I have heard for RFID tags that are based around intrecate information models, or complex device interactions is incredible.

One idea that I have had, that RFIDs could simply and effectively achieve, is object identification. One thing RFIDs are great at is identifying stuff. You write a bit of code into the tag that says “I am an X”. Simple.

If you want to be a tiny bit more complex, you add certification to say who created this information. Along the lines of SSL certificates on the internet. This means that you not only know that the tag is an X but also that Y said it. So Y has identified X for us.

Now, the cool bit. RFIDs are basicly transponders. They are passive devices, require no batteries, and can just sit around happly all day doing nothing until called on. So if you embedded and RFID in say a door, you wouldn’t need anything, but glue it in.

The idea of RFID eyes, is to take this simplest of features of RFID tags and use it to give an auditory indication to people with visual impairment of where and what something is. RFID tags only activate when a reader is close enough. There is also nothing to stop someone from making a ‘narrowband’ reader that was highly directional. Think of something like a satellite dish, but on a smaller scale. The man from Sky has to come and fit it, so that it points in the right direciton otherwise you can’t recieve the broadcast.

What I would like to see is a device which a person could cast around with, and get an auditory (or even dynamic braille) output, describing what they are pointing at. “You are pointing at the Ladies’s toilets” for example could save some embarresment for the gentleman.