Are accessibility sites fatally flawed?

These are articles that you need to read:

  • Mike Davies: BarCamp London Accessibility Panel Thoughts

    Mike Davies is a great writer with some very refined thoughts about web accessibility. He also has some very strong opinions against universality. In this article, he describes what he perceives as a need for the accessibility community to create a strong voice which will discuss accessibility while completely excluding universality.

  • Mike Cherim: Failed? Fundamentally Flawed?

    Mike Cherim responds to Davies comments. Although agreeing with much of the article, Mike, the founder of one of the sites criticized, takes issue with the accusation that the sites mentioned as failed or flawed are what Davies describes. The main issue is this question of universality – Davies considers universality to be a dogmatic, pervasive poison in the accessibility world. Mike takes issue with this.

  • Web Standards Project (Ian Lloyd): Failed and Flawed Accessibility Organisations

    Ian raises the question again about whether this organizations are really flawed, and asks his readers for their opinions on what a “fixed” accessibility organization would be.

Mike Davies’ opinion, apparently, is that any organization which espouses universality and accessibility simultaneously is fatally flawed. Obviously, any forum is flawed by definition, since the open forum format can not justifiably exclude people with a different opinion. More closed organizations are flawed if they publish their opinions which promote universality at what he perceives to be the expense of accessibility.

I absolutely can’t agree that Accessifyforum is flawed – members of the forum may have opinions which differ; but that’s the entire point of a forum. The forum still provides better information for new practitioners of accessibility than they might find in many contexts. As to other accessibility sites? Yes, they’re flawed by Mike’s definition. But I’m not sure that I can agree with Mike’s opinion.

The problem, for me, is that I don’t really agree with Mike’s opinion about what a “universalist” is. Mike says:

You can spot a universalist wearing an accessibility disguise by listening to their rationale as to why a website is not accessible – this includes whoppers like “Flash isn’t accessible because it doesn’t work in Lynx”, and “its inaccessible because it doesn’t validate”.

In my opinion, the person saying these terms is not a universalist: instead, they’re missing the point. They’re missing the basic understanding of accessibility – to provide access to content. More appropriately, “Flash isn’t accessible to Lynx users.” This is a valid statement. However, so might be “Lynx isn’t accessible to users with cognitive impairments.” Harder to verify, since it’s not impossible for a cognitively impaired user to use Lynx – but a site created with Flash, using larger, colorful buttons, images, and sound could be more usable.

Accessibility is not purely a function of technology: it’s a function of audience. Universalists attempt to make a site open to the widest possible choice of audiences. This will still potentially eliminate some audiences. The same is true of any accessible site: the important thing, however, is to make the site available for your audience. Knowing your audience is not a simple fact; but it’s the thing you need to pay perfect attention to in order to create an accessible site.

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.

Have something to contribute?




« Read my Comment Policy

10 Comments to “Are accessibility sites fatally flawed?”

  1. Thanks, Niqui! Where is this workshop taking place? Is it online? Your website doesn’t say…

  2. 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

  3. Thanks for jumping in, Mike. I wasn’t really knowledgeable enough to make any thorough counter-arguments on these statements. I should have noticed the issues you mentioned regarding JAWS and Windows Eyes, however…there are many outside issues requiring users to make use of one software set over another, most of which are outside of our control.

    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.

  4. Benjamin says:

    “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.

  5. Whew. Thanks, Benjamin – that was very insightful. It sounds to me like you’ve really put some research and attention into the Flash accessibility question.

    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.

  6. The funny thing about “Flash isn’t accessible because it doesn’t work in Lynx” is that it actually does, though not well (if you’re running Lynx in an X terminal (like xterm, Konsole, or GNOME Terminal), you can launch the standalone Flash players for Flash content). A serious thing about it is that on Linux, Solaris, and BSD, text browsers like Lynx continue to offer the best general web access to the blind. (Work is being done to remedy this with Firefox 3.) Platform choice can constrain browser choice.

    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)”?

  7. Thanks, Derek. Productivity is, shamefully, not always the focus on these disputes. If there’s any real problem with the accessibility world it’s the fact that we do not always keep our focus on being polite and respectful.

  8. Gentlemen – thank you for both posting your comments in what seems to have been the most productive and clarifying post/comments on this matter so far.

  9. Thanks for your response, Mike. I’m sorry that I misunderstood your separation of universality and accessibility — I will say, however, that this is the impression your article gives. I’m reasonably confident I’m not the only person who perceives this.

    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.

  10. “Mike Davies’ opinion, apparently, is that any organization which espouses universality and accessibility simultaneously is fatally flawed.”

    No. My opinion is that any organisation which espouses universality _as_ accessibility is a failure. An organisation that professes to support accessibility should support accessibility.

    There’s nothing wrong with espousing universality in its own right – its a vision founded on the original vision of the Web. Unfortunately that vision and goal wasn’t enough to prevent the exclusion of people with disabilities. Accessibility is there because universality failed to meet the needs of disabled people online.

    “but a site created with Flash, using larger, colorful buttons, images, and sound could be more usable.”

    And, in certain cases, more accessible (you’ve hit the nail firmly on its head with your statement that accessibility is a function of the audience, not technology). Flash is content, where its strengths fills a number of gaps where HTML as content fails.

    “The problem with Flash is that the majority of designers don’t know how to use it to build an accessible web site.”

    The exact same thing can be said of HTML and CSS. Its not a failing of the technology, its a failure of the developer.

    “The most valuable thing I can imagine would be a training course on Flash design with accessibility in mind.”

    Absolutely. This is essential for moving accessibility forward. The problem is, there’s a very vocal community out there that will not tolerate Flash being promoted in this way.

    “I’d certainly sign up.”

    So would I.

    Although I don’t agree with all the points you make in your post, I thank you for taking the time to post a considered and pragmatic reply.

Return to Top