The problem with Flash is that the majority of designers don’t know how to use it to build an accessible web site. The most valuable thing I can imagine would be a training course on Flash design with accessibility in mind. I’d certainly sign up.

I have my first Flash workshop planned for next month. I have more information about my Flash Accessibility workshop on my blog.

Thanks for the interesting read. Niqui

I’ve edited both your comments to add blockquotes; I hope you don’t mind. This makes it easier for me to track the conversation.

The price of Windows and the price of Windows-based screenreaders is not the fault, nor the responsibility, of the web developer. Its fine if you personally want to protect the choice of open source, but forcing it on others isn’t a reasonable option.

Thanks for saying this.

“So we really need to balance the purported accessibility benefits of Flash against the known accessibility costs, which involve forcing users who are blind or motor-disabled to use an expensive, closed-source operating system and an (arguably) inferior web browser.”

Considering that both JAWS and Window Eyes are the most popular screen reading software out there makes your claim of “forcing users who are blind … to use an expensive, closed-source operating system” is mostly fallacious. JAWS and Window Eyes require Windows already. And considering that Windows comes with Internet Explorer already installed - the requirements for JAWS and Window Eyes users are not as onerous as you imply.

Benjamin goes on to say:

“It is to protect the capability of disabled users to access web content with other (and, especially, free and open source) browsers and platforms.”

The price of Windows and the price of Windows-based screenreaders is not the fault, nor the responsibility, of the web developer. Its fine if you personally want to protect the choice of open source, but forcing it on others isn’t a reasonable option. If open source can’t keep up with web technology improvements and innovations, then that’s a problem the open source movement needs to deal with.

The web developers job is to ensure that the content they produce is accessible using the technology they have selected as best fitting their content and audience. After that, it is the user’s responsibility to ensure that the technology choices they make are sufficient to allow them to access accessible content. If open source fits the bill, so be it. If it doesn’t, then its that product’s developer that’s responsible for the shortfall, not the website developer.

On problems with open source development, Benjamin says:

“Nobody seems to be in a rush to tackle that one however, and in any case Gnash’s feature-set lags behind Adobe’s own plugin.”

Well, you could start by collecting up all screen reader users on non-Windows platforms to raise their concerns with these developers, or directly with Adobe. Its quite obvious why Adobe focused on Internet Explorer and JAWS/WindowEyes - because that is the dominant software choice for screenreader users.

Benjamin says:

“I’ve found that questions to blind user mailing lists about whether a given Flash site is accessible with screen readers are typically answered by a few brave testers finding that no, it isn’t, and a chorus of people saying they wouldn’t even bother to try it because their experience of past Flash sites has been so poor.”

Yes, there’s a perception problem, and that needs to be tackled. People will chose not to use certain websites for any number of reasons (rational or not). Making that choice doesn’t necessary entail a form of discrimination, particularly when the content is accessible.

Benjamin says:

“To sum up, if you want to know who’s killing accessible Flash, you need to look to Adobe”

I’ll disagree with that - Adobe have been making a great deal of progress in the last few years towards accessibility of its Flash platform (as well as with PDFs). On Wednesday I saw, again, a demonstration of a number of examples of accessible Flash, working almost seamlessly with a screenreader. Its very impressive, and it works today with today’s technology.

I won’t argue you with you that Flash has problems. I’ve said before that the reason I, personally, don’t use Flash is because I don’t know it well enough to use it appropriately. If I did know it extremely well, I would conceivably continue to choose not to use it, or use it very selectively.

There are a couple of arguments you make which I take issue with, however. First:

Whether Flash is really a more suitable format for producing content for that audience than SVG or SMIL is probably debatable.

If you’re going to raise complaints about the inconsistent support and therefore accessibility of Flash, you can hardly turn around and consider SVG or SMIL anything recommendable. Perhaps in another 5 years they’ll be usable media, but as it stands they will place many of the same barriers to accessibility as Flash. Regardless even of support, the Flash plugin is significantly more widely implemented and therefore a “safer” choice.

Second:

Requiring the Flash plugin is the equivalent of telling blind users: “This content requires Internet Explorer.” That’s because Adobe’s plugin does not expose information to the Microsoft Active Accessibility framework from Gecko browsers on Windows or to accessibility frameworks on *nix platforms (Mac, Linux, Solaris, etc.) at all.

In this case, I’m not going to argue with you on my own behalf. I agree that this is a major problem in making a supportable case for Flash. However, I think that Mike’s point is a little different from this: he’s making the case that a website needs to be made accessible to it’s very particular users needs. A website which goes out of its way to cater to screen readers which is intended for a cognitively disabled population may be pursuing a track which will encourage universality at the expense of its target audience.

The ultimate source of this debate is a matter of audience, I think. Universalist accessible web developers will focus on providing access to all, possibly at the expense of a core demographic for that resource. Other accessible developers may focus on that core demographic to the exclusion of other potential visitors.

Neither answer is actually perfect in any way. The best answers don’t yet exist - full content negotiation in response to the user’s preferences.

Thanks very much for your contributions, Benjamin.

Joe Dolson’s point about accessibility for the cognitively challenged is an important one. Whether Flash is really a more suitable format for producing content for that audience than SVG or SMIL is probably debatable. Indeed “using larger, colorful buttons, images, and sound” seems implementable in HTML anyhow. But personally, I see nothing essentially wrong with Flash in theory and would voice strong support for “a training course on Flash design with accessibility in mind”.

However, in practice, currently Flash does raise very serious accessibility challenges. Whereas much ordinary HTML content is somewhat accessible to blind or motor-impaired users, seemingly most Flash content is seemingly not. Because HTML is primarily textual and mostly relies on the browser’s own user interface, it gets a lot of accessibility for these constituencies “for free” (although it’s not hard to break that UI with JS). By contrast Flash’s accessibility feature-set seems to have been a more recent add-on. Judging by the fact that much Flash produced today continues to fail to use that feature-set, Adobe have not produced authoring software that is sufficiently opinionated about accessibility issues. So how might this be fixed? Maybe Adobe need to require authors to decide whether a given bit of content communicates or decorates, and make including text for communicative content and adding keyboard triggers for events an ordinary part of the workflow.

But, pace Dolson and Davies, it is not only a matter of reeducating Flash authors, since the accessibility of Flash players is dire. Requiring the Flash plugin is the equivalent of telling blind users: “This content requires Internet Explorer.” That’s because Adobe’s plugin does not expose information to the Microsoft Active Accessibility framework from Gecko browsers on Windows or to accessibility frameworks on *nix platforms (Mac, Linux, Solaris, etc.) at all.

Is it acceptable for requiring the “right set of technology” to mean requiring Internet Explorer? When WCAG 1.0 discussed user agent requirements, it stressed that:

1) Users “may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system”.

2) Authors should “provide additional support for accessibility until most user agents readily available to their audience include the necessary accessibility features”.

When WAI discuss baselines in WCAG 2.0, they say: “One reason it is important to be technology-specific rather than user agent specific is that restricting users to specific user agents may pose insurmountable accessibility problems for some people.”

So we really need to balance the purported accessibility benefits of Flash against the known accessibility costs, which involve forcing users who are blind or motor-disabled to use an expensive, closed-source operating system and an (arguably) inferior web browser. To assert, with this in mind, that Flash should have a non-Flash fallback is not to poison the knife against Flash. It is to protect the capability of disabled users to access web content with other (and, especially, free and open source) browsers and platforms. This is partly important because free and open source solutions empower disabled users to get to the root of accessibility problems and get them fixed. For a lengthier exposition of this point, see Joanie Digg’s blog.

So how might this situation be addressed so that Flash does not need a fallback? We can either hope that Adobe decides that blind users can expect to use Flash content with other browsers than IE and other platforms than Windows, or Flash accessibility advocates can get stuck in to creating a more interoperable Flash plugin themselves. An obvious line of attack would be to expose Gnash (the GNU flash player) to first AT-SPI and the Apple Accessibility API, then MSAA. Nobody seems to be in a rush to tackle that one however, and in any case Gnash’s feature-set lags behind Adobe’s own plugin.

It’s true that criticism of particular formats can cement into kneejerk distaste, but this is true of users as much as of web designers. I’ve found that questions to blind user mailing lists about whether a given Flash site is accessible with screen readers are typically answered by a few brave testers finding that no, it isn’t, and a chorus of people saying they wouldn’t even bother to try it because their experience of past Flash sites has been so poor.

Nor does it make sense to say Flash is great for the cognitively challenged, while those who are blind or have motor disabilities can can be served with standard HTML, CSS, and JS. Because of course, some people are both, and they deserve to be catered for too.

To sum up, if you want to know who’s killing accessible Flash, you need to look to Adobe not Accessify Forum. In fact, the denizens there tend to react to (rare) questions about accessible Flash in a positive manner. See the following threads for examples:

1. accessible Flash examples please…

2. Getting JAWS tp play Flash Video

3. proposed reorganisation of accessify’s topics

4. Flash MX and JAWS

5. Does Bobby help to check Flash accessibility?

So why is Accessify Forum not a place “where content creators can work together on accessibility, regardless of the content technology (HTML, Flash, SVG, Canvas, multimedia)”?

I see your point quite clearly — - the polar opposition to Flash and other rich media formats which the accessibility community frequently exhibits seems like a position based on ignorance or laziness much of the time. I have an open mind to the implementation of rich media - it’s not a method I would specifically exclude.

I don’t, however, believe that the problem is as severe as you do. The vast majority of websites are, in my opinion, best served with a simple HTML/CSS implementation.

I tried to be practical in my approach, and appreciate your observations.