by AWK

 Comments (23)

Created

February 3, 2009

This post is subject to Adobe's Terms of Use.

WebAIM released the results of a survey of screen reader users and the results are interesting for what they tell us about HTML use, but the commentary around user’s thoughts on Flash content and PDF documents is of particular interest at Adobe. The results state that 71% of screen reader users responding feel that Flash content is very difficult (34%) or somewhat difficult (37%) to use, and 48% of screen reader users responding feel that PDF documents are very difficult (17%) or somewhat difficult (31%) to use. I think that it is worth putting some additional context around these numbers.
Given that the Flash player has supported accessibility since 2001 when Player 6 was released, and the Flash authoring tool provides support for developers to add accessibility to Flash content, why are Flash developers not adding necessary information to their projects? Some are, to be certain — there are examples of Flash being used properly such as what is offered at Social Security (http://ssa.gov/pgm/flash/overviewcaptioned.htm) and the U.S. Department of Education (http://federalstudentaid.ed.gov/mystory/index.html) web sites, but you don’t need to look too far to find inaccessible examples.
Flash is a tool to make content, but many developers aren’t providing the necessary information. We’ve published books with information relevant to the topic such as Web Accessibility: Web Standards and Regulatory Compliance which I contributed chapters to and Universal Design for Web Applications: Web Applications that Reach Everyone which Matt May on the Adobe accessibility team co-authored with Wendy Chisholm. We also have information available at the Adobe Accessibility web site — please point these resources out to Flash developers who don’t make their content accessible.
The story is similar for PDF documents – there is tooling readily available to make PDF documents and forms accessible, and many authors do take the time to add necessary accessibility information, but not everyone does. For PDF, please point authors to the Acrobat 9 accessibility guides at http://www.adobe.com/accessibility/products/acrobat/ or to the Web Accessibility: Web Standards and Regulatory Compliance book chapter on PDF.
I feel that it is important to not over generalize from the WebAIM survey data for Flash and PDF. It is fair to say that users are rating these formats less favorably than any of us would like to see but that does not mean that the formats are not accessible. Users have interacted with examples in these formats from which they have formed impressions but that does not mean that developing accessible content in Flash or PDF is impossible. This idea is echoed in Adrian Higginbotham’s comments to the WebAIM blog announcement of the survey results where he acknowledges challenges with some Flash content but finds success with others.
Flash and PDF are tools and the accessibility of the content depends on whether the developer is making an effort to produce accessible content. Please encourage authors and developers to handle accessibility properly.

COMMENTS

  • By Thea - 2:23 PM on February 3, 2009  

    I want to make sure that people know that Flash that has been made accessible is not difficult, if not easier to use than HTML content. These survey results come from the fact that there is just more inaccessible Flash content than HTML content on the web. This comes from its dynamic nature, Flash can quickly become inaccessible, when it has not been programmed for accessibility, more so than HTML content. Dynamic content also comes with the stigma that it cannot be made accessible.
    I would like to add to the resources listed our Flash developers guide for accessibility: http://www.doodledoo.com/accessibility.htm It takes Flash developers through a few quick and easy steps to make Flash accessible.

  • By Marco Zehe - 3:54 PM on February 3, 2009  

    The story is similar for PDF documents – there is tooling readily available to make PDF documents and forms accessible, and many authors do take the time
    to add necessary accessibility information, but not everyone does.

    And I believe this is one of the big big problems of both PDF and Flash: You have to go through a manual process to add accessibility to both formats. With HTML, unless one really fouls up markup, one usually gets decent access in browsers that support accessibility. Writing Windows client software using common tools usually gives fairly accessible applications. Same goes for GTK apps on Linux or Cocoa apps on Mac OS X.
    There are so many automated PDF creation mechanisms out there, and none support at least some accessibility by default. An example is a newspaper service which generates articles or issue pages automatically upon request, but that process is missing accessibility information, even though the source format may provide the necessary info to automate this. The result may not be 100% perfect, but 90% is usually better than inferring the reading order from the document, which usually fails badly on newspaper layouts.
    Same with Flash: If a button is added, and a caption entered, the tools should automatically generate the correct accessibility information and not require authors to take extra steps, or worse, read whole books on the subject.
    This is–and I speak from purely personal observations here–one of the big problems PDF and Flash accessibility had from the beginning: There was no, or no advertised, way of automating the process without manual intervention on a wide scale.

  • By Andrew Kirkpatrick - 5:17 PM on February 3, 2009  

    And I believe this is one of the big big problems of both PDF and Flash: You have to go through a manual process to add accessibility to both formats.

    Marco, the additional effort that I’m talking about is for things like equivalents for images and ensuring that form controls have labels. All formats require this extra work.
    If you create a PDF or Flash file, most information is exposed even if you don’t try at all. Where the trouble starts is that people generally make Flash content more complex than the average web page and in any format as complexity of the asset increases so does time needed to attend to accessibility.

    Writing Windows client software using common tools usually gives fairly accessible applications. Same goes for GTK apps on Linux or Cocoa apps on Mac OS X.

    As long as you stick to the standard control set and stay on the path with best practices that is true. It is also true for Flex, our Flash-based framework and for PDF forms and documents also. When developers go off the path they often create accessibility challenges that need to be dealt with, whether using Flash, Flex, Cocoa, Win32, Java Swing, or HTML/JS/CSS.

    There are so many automated PDF creation mechanisms out there, and none support at least some accessibility by default.

    I think you missed the one that Adobe makes – Adobe LiveCycle. It supports the generation of accessible PDF documents by default.

    Same with Flash: If a button is added, and a caption entered, the tools should automatically generate the correct accessibility information and not require authors to take extra steps, or worse, read whole books on the subject.

    TheFlash authoring tool does exactly what you describe. If you create a button and put text as the caption, all of the necessary accessibility information is automatically created. If you use an image instead of text, you need to add an equivalant.
    By the way, it is only one chapter in the book that is on Flash best practices, so it won’t take too much of your time…

  • By Ricky Buchanan - 11:50 PM on February 3, 2009  

    I feel that there is a disconnect here between what users are experiencing and what Andrew is pointing out is possible because you are talking about two very different things.
    Andrew is pointing out that it’s possible to make PDFs and Flash content accessible. This is true.
    The user survey is displaying that most users are finding that most Flash and PDF content is inaccessible. In my experience, this is also true. I am not a screen reader user, but I do use assistive technology and run a blog about AT on Mac OS X.
    This quote particularly illustrates the disparity:

    I feel that it is important to not over generalize from the WebAIM survey data for Flash and PDF. It is fair to say that users are rating these formats less favorably than any of us would like to see but that does not mean that the formats are not accessible. Users have interacted with examples in these formats from which they have formed impressions but that does not mean that developing accessible content in Flash or PDF is impossible.

    The survey asked, and says, nothing about whether it’s possible to make a format accessible. It talks about users experiences with examples “in the wild”. I don’t see why anybody would even think to generalise from “screen reader users find most Flash/PDF content hard to use” to “it’s not possible to create accessible Flash/PDF content”. The users aren’t rating the formats – they’re rating the implemented content they’re encountering.
    Unfortunately, given the ongoing battle with things like ALT attributes on images – something generally trivial to add – I’m not surprised that Flash and PDF authors aren’t making accessible content. Most of them either don’t know or just don’t care unless – as in the USA government websites you cited – they’re legally required to.
    I don’t have any more solutions to it than you do, I just felt that your comments were implying that screen reader users were incorrectly assuming inaccessibility, and I really don’t think that’s the case.

  • By Andrew Kirkpatrick - 8:34 AM on February 4, 2009  

    Ricky,
    I agree with you – I don’t think that the users taking the survey believe that Flash or PDF can’t be accessible (although some might) but the way the data is presented is the problem – the results say “71% of screen reader users find Flash difficult to use”. This is not normalized for anything which makes the analysis a challenge. The main conclusions to draw from the data is that a large percentage of users are not confident that they will have a good experience when happening upon Flash content and a smaller percentage are, but I’ve seen it happen too many times where a survey is used to say “see! Flash (or accesskeys, or skip nav links, peanut butter, Hillary Clinton, or anything else you can imagine) is bad because people say they don’t like…”.
    I’m glad the the study was done, but wish that there was more detail in the Flash and PDF questions because that detail is important.

  • By Steve Buell - 5:57 PM on February 8, 2009  

    I agree that both Flash and PDF files can be made more accessible with increased knowledge on the part of the content producer.
    These improvements in the tools are iterative, as is the skill level of the designer/developer.
    Should there not be active prompts or steps that must be taken to finalize the out-put from these tools which will result in more accessible content?
    Most content production tools- IDEs, CMS’-don’t produce accessible content as a default and leave it to others to instruct/enforce accessibility.
    Heck, my car tells me when I’m about to do something stupid like leave the key in the ignition. Should it be so hard for a software program to tell a “web designer” that they are about to produce an object that 10-20 percent of their audience can’t use?

  • By Kerry Webb - 6:30 PM on February 8, 2009  

    One thing that Adobe could do is to enable the Accessibility option in Flash by default, ie the developer would have to disable it so that they weren’t prompted to do the right thing.

  • By Andrew Kirkpatrick - 1:47 PM on February 9, 2009  

    Kerry – in general Flash content this is the case already. It is accurate to say that accessibility needs to be enabled for UI components in Flash, but general Flash content doesn’t need to be enabled. Developers just need to provide the information.
    Steve – prompting for accessibility information is a trickly thing and I don’t think that comparing it to your car reminding you to not leave your keys in side it is a fair comparison. In Flash a developer might create an object that needs and equivalent in many different ways (e.g. drawing, importing, combinations of both) and the same processes are just as liklely to result in something that wouldn’t require an equivalent so there is a possibility of significant “chatter” for the developer. In some cases (e.g. button with no text inside it) we could and should do what you request.
    I’m not trying to slough responsibility, but since there are a lot of PDF files that are created from MS-Word, shouldn’t Word request the author provide the data?
    If you have suggestions for well-defined processes within Flash or Acrobat please pass them on and we’ll take a look at them and see what we can do.

  • By Joe Rothschild - 3:39 PM on February 24, 2009  

    Uh… no.
    You said: “there are examples of Flash being used properly such as what is offered at Social Security (http://ssa.gov/pgm/flash/overviewcaptioned.htm)”
    The example you provided is not accessible, nor is it compliant. If you test the page using JAWS, you’ll see that the video player buttons are a) not properly labeled, and in firefox they’re not even read.
    It irks the heck out of me that it is so hard to find ACCURATE information about creating compliant (508) and accessible flash out there, even information straight from Adobe.
    Pardon my rant, but when Adobe points to an inaccessible example and call it “Properly used flash” when even a basic test would have revealed that as a false claim, it makes my blood boil.
    Come On Adobe – get your act together and solve some of the accessibility problems that we’ve been shouting about for the last 2-3 years.
    Don’t worry, I’m not mad at you – I’m just dissapointed in you.
    Joe

  • By Andrew Kirkpatrick - 3:55 PM on February 24, 2009  

    Joe,
    I think you are possibly doing something wrong. This is an accessible example. Here’s the MSAA data:
    Window: 0x00500C42 class=”MacromediaFlashPlayerActiveX” style=0×56000000 ex=0×0
    Children: none [mnfd] : animation : normal
    “Pause” : push button : focusable
    “Volume Mute On” : push button : focusable
    “Show Captions” : push button : focusable
    and here’s the audio recording of my reading the files with JAWS and IE7 (I got the same results with JAWS and FF):
    SSA video and Flash in JAWS audio recording.
    Please, try again, and let me know what you find.
    AWK

  • By Joe - 7:28 AM on February 25, 2009  

    Thanks for the quick reply Andrew, and thanks for the audio – but I have a rebuttal clip.
    http://www.joefreelance.com/GUEST/JAWS.wav
    This is what I got when listening to it using JAWS 8.02173U and Firefox 3.0.6
    None of the buttons were tabbable, and the flash movie appeared empty. (Flash Movie Start- Flash Movie End)
    I don’t mean to bash anyone, and I’m sure you feel my pain in the world of flash and accessiblity. It just drives me buggy that there is so little reliable, consistent info on the topic. That’s not Adobe’s fault, after all, they’re making giant strides in the realm of accessibility.
    Thanks for all that you do-
    Joe

  • By Andrew Kirkpatrick - 9:28 AM on February 25, 2009  

    So we have part of an answer for you. You told me that you are using Flash Player 9.0.45.0 and support for accessibility information in the Firefox plugin came in with 9.0.115.0 (see http://blogs.adobe.com/accessibility/2007/12/new_flash_player_with_msaa_on.html for a reference).
    The other part of your post indicated that you were hearing buttons not labeled correctly when browsing with IE. I’m not sure why that’d be happening – did you try it again on IE?

  • By Joe - 2:32 PM on February 25, 2009  

    Hey Andrew,
    Thanks for the info! That really clears things up. In IE, we don’t have problems, it’s just in FF.
    Joe

  • By Andrew Kirkpatrick - 2:37 PM on February 25, 2009  

    Joe,
    glad to help.
    So if IE/JAWS wasn’t a problem, what did you mean in your initial message when you said that

    “the video player buttons are a) not properly labeled, and in firefox they’re not even read”

  • By Jim Tobias - 12:57 PM on March 1, 2009  

    The problem that we see here — a tool capable of creating accessible content but only with the active participation of the content creator — is widespread in the world of accessibility. It’s a value chain issue, and you can see it in phone systems, learning management systems, etc. Unless everyone involved implements accessibility properly, users do not get the benefit of anyone’s efforts.
    The point is not to bash any link on the chain, but to discover what the current impediments are to further adoption, usually some combination of tool defaults/prompts, tool-specific training and reference materials, professional awareness, and customer nagging. The former two are links within the domain of the tool seller. I’d say Adobe has done a pretty good job on them, exemplary in some respects.
    (Another unrelated issue is that some users hear about accessibility problems in early versions but do not hear about improvements, and both avoid the content and perpetuate the rumor. As in, “You never get a second chance to make a first impression.”)

  • By Carla Hawks - 10:56 AM on March 2, 2009  

    I don’t know about Flash, but with Adobe PDF document creation the process to make the document accessible is so tedious and time consuming I would say that is the reason developers don’t make Adobe PDF docs accessible.
    Adobe needs to automate this process (more) in their applications so the time to make PDFs accessible isn’t so time consuming.
    Carla

  • By Teresa Mills - 11:18 AM on March 2, 2009  

    I would like to add a couple of comments:
    1. In some cases, some web applications and Flash applications may be accessible–maybe even meeting your organization’s accessibility policy and criteria–but yet by design are extremely difficult for people with disabilities to use–particularly those who are blind or have low vision. Expert screen reader users will do better than novices, for example, but sometimes even with accessible Flash, they can get a bit lost on complex designs and when things are changing around on the screen(similar to AJAX) with no indication ot the screen reader. In addition, to accessibility testing (does it meet a set of standards and criteria?), I would like to see some usability studies. Particularly what are screen reader users having problems with when Flash is accessible, but they are they are having trouble using it? Is it a limitation in the AT (which will all know each version of of JAWS has it’s own quirks and bugs) or is it that we have an inexperienced user who does not know how to use the features within their screen reader. Believe it or not, I have gotten complaints from customers using screen readers that tables and forms were inaccessible in html. They did not know how to use table reading commands or how to go into forms mode in JAWS.
    2) I think we are often too JAWS focused. What about Window-Eyes users and other types of AT such as Magic, ZoomText, and Dragon Naturally Speaking?
    3.As I have mentioned AT has bugs, IE has bugs, Firefox has bugs; thus, it is important to know the limitations of all software that you are using when testing. We have standards to help make determinations about accessibility. I reviewed a web page with Flash other day, which was quite simple, but JAWS 9 did not read it correctly. I then used Object Inspector to look at the code, which was correct. Then I tested using Window-Eyes 7, and it read it correctly, like the code in Object Inspector. Was it not accessible because it did not read correctly with JAWS 9? In this case, no (not according to the 508 standards 1194.22 and 1194.21), although if your customers have JAWS 9, you know that they will not be able to read it easily, if at all–which produces inner conflict for me.
    4) I hate to say this, but my job is testing for 508 Compliance at a Federal agency, and I rarely see accessible Flash. I often see PDF documents that are untagged or not tagged correctly (common problems: reading order, untagged graphics, forms. I often hear about Flash, this can not be made accessible. Yet often, with some tips from Andrew Kirkpatrick, the developers can make it accessible. Thus, developers need to learn more about making Flash accessible so I would like to see more learning tools such as videos, tutorials, and case studies on Adobe.com. Although I realize that Adobe has some resources, I am saying more please.

  • By Andrew Kirkpatrick - 11:21 AM on March 2, 2009  

    Carla,
    That really depends on the ind of document that you are creating and whether you have considered accessibility at the outset. As with other formats, if you neglect accessibility at the outset you have a harder time later on.

  • By Vivek Gaikwad - 7:33 AM on March 12, 2009  

    I don’t see any developer commenting here. They are the real makers of this. I think the information is not reaching them or they are just not concerned about flash and accessibility because they are not liable to it. They are creating the applications the way it is told to them.
    Creating Accessible Flash is that easy as the day the developers want to make flash accessible, they will succeed. It’s just that, the decision makers need to allot a little bit (may be 5%) extra for making flash accessible, which is applicable to any other technology and not only flash in particular. If this happens then will see accessible flash all over the web.
    peace, veiky
    Flash accessibility developer

  • By Shilpi - 4:52 AM on March 19, 2009  

    As a company we work with accessible development in the area of HTML, PHP, Flash, etc, what we notice is that firstly the developer needs to understand the concepts of accessibility. For those that say in HTML you can’t go wrong, see a large part of the web and you will notice that compliance is lacking. The only difference as i see it is that in Flash, it has got set in people’s mind and this is the easy route for them to say “In Flash the cost will be higher or then this is not possible in Flash”.
    In HTML if we have to add an alt text, in flash we have to go a name and a description. Its really not that difficult.
    We have even developed a course authoring tool that from an LMS Plugin (that we have developed) a accessible flash file is developed.
    I think its a mindset and a training issue!

  • By jc ehle - 10:10 AM on June 15, 2009  

    “Flash and PDF are tools and the accessibility of the content depends on whether the developer is making an effort to produce accessible content.”

    Not entirely the case. We just ran into the issue of creating flash content that is accessible and after reading then re-reading documentation on adobe’s site:

    http://www.adobe.com/accessibility/products/flash/best_practices.html

    http://www.adobe.com/accessibility/products/flashplayer/overview.html

    http://www.adobe.com/accessibility/products/flash/faq.html
    we still couldn’t figure out why the screen reader wasn’t picking up any of our accessible content.

    Turns out the issue is the wmode setting in the embed, and once you know what you are looking for it becomes quickly apparent that this has been an issue for some time.
    You HAVE to have wmode set to “window” in order to have screen readers pick up accessible text on your Sprites, buttons, etc…
    “opaque” and “transparent” modes will break the screen reader’s functionality. This little quirk took us (~20 years combined experience with flash) WAY too long to sort out.
    Adobe has been calling this a “feature” for over 5 years. My opinion is that it is a very dodgy feature and should be better documented on the accessibility pages on adobe’s own site. Or fix it.

  • By Hugo Matinho - 12:47 PM on June 22, 2009  

    Hello Everybody,
    Ok someone said that developers aren´t posting here and we are the makers of this and I couldn´t agree more.
    when people state Flash isn´t accessible, i tell them it´s wrong Flash supports accessibility since player 6
    we just don´t implement it because:
    - most of us have tight deadlines and projects don´t usually contemplate accessibility, which is wrong.
    - most of us don´t even know flash could do that ( i usually hear people say “oh flash doesn´t support accessibility”) maybe we should read more and lose some time doing some research it´s allways easier to say it doesn´t work.
    - sometimes we just don´t implement it right, people do mistakes.
    Adobe has always helped the community, i´m not saying Adobe is always 100% right but i´m saying it´s easier to “bash” on someone or on a company´s ears.
    software has bugs and they get corrected most of the time when we´re talking about adobe software and I can garantee that because I work with flash since Flash 4 and i read stuff people post about flash because it´s my field of work.

  • By Black Friday Kindle Fire - 1:32 PM on October 20, 2011  

    As a Newbie, I am permanently browsing online for articles that can benefit me. Thank you.