Archive for the 'Accessibility' Category

Accessibility and Flex: we can do better.

Published on May 3, 2008 in Accessibility and Flex. 4 Comments

By default, Flex Builder creates inaccessible SWF files.

Bad decision. This needs to change.

Enabling accessibility features for The GAE SWF Project resulted in an 8KB file size increase in the SWF file. I can live with that. Creating inaccessible SWF files to save a couple of KB is no savings at all.

The Flex accessibility overview page feels woefully outdated and mention Adobe Flash Player 7. We're on 9 now. Let's update these, guys!

It also reads more like marketing talk then factual information for developers with phrases like "designers and developers can create powerful, exciting, and engaging experiences on the web that are accessible to all" and "it's never been easier to design accessible Rich Internet Applications." Let's cut out the marketing talk and concentrate on the facts. If we feel that we need to dilute or detract from the facts with marketing talk, maybe we need to concentrate on changing the facts.

The Accessibility Best Practices for Flex document, on the other hand, does an admirable job of disseminating important information that is useful for developers.

It is also important to note that the accessibility features of the Flex components have been optimized for use with JAWS on Windows and that users will need to install additional JAWS scripts to enable these features. Why aren't these scripts included by default in JAWS?

The best practices document is very useful but I feel that we would benefit for a short, succinct and no bullshit summary to quickly inform developers on the state of accessibility in Flex. Something along the lines of:

The State of Accessibility in Flex

  • Accessibility is not enabled by default for Flex applications (ideally with a note stating: "We will be changing this in the next release.")
  • Accessibility in Flex is optimized for JAWS on Windows. (This is not necessarily a bad thing; better to have great support for one accessibility aid than shoddy support for several.)
  • JAWS users will need to install additional scripts to take advantage of advanced accessibility features.
  • Accessibility is more than adherence to standards and screen-reader support. For a full discussion, read Accessibility Best Practices for Flex.

Finally, bookmark the Accessibility Resource Center on Adobe.com and keep checking back for new articles (and bug Adobe if you don't see any!) :)

The times they are a-changin’

Published on August 13, 2007 in Accessibility, Community, Flash and Web standards. 5 Comments

Someone called Mike attempts his five seconds of Internet fame by claiming that Flash Sucks and Web Standards and accessibility guru Mike Davies counters with a post titled Growing momentum behind accessible Flash.

This follows Drew McLellan's post on the WASP blog on Obstacles to Accessible Flash which highlights current accessibility issues that Flash is affected by due to browser limitations and other reasons, both Adobe-related and non-Adobe-related.

There is today more communication and understanding between the Flash and Web Standards communities than ever before. I've been trying to do my tiny little bit by actively encouraging this communication whenever possible and I've been very fortunate to have had the invaluable support of my friends Andy Budd, Jeremy Keith, Mike Davies, Christian Heilmann, Drew McLellan, Tom Croucher, Steve Webster, Pete Barr-Watson, Heather Ford, Lawrence Lessig, John Davey and many others in both the Flash and Web Standards communities.

I feel that it's essential that we keep this communication going and one way to do this is to get Flash people to speak at non-Flash events like d.construct and have Web Standards people speak at Flash events (Jeremy Keith at last year's Flash on the Beach and, this week, at Flash Brighton).

It feels like we've come a long way in the last two or three years in dispelling myths and misinformation about Flash and in getting Flash developers exposed to web standards and concepts such as progressive enhancement. There's also a lot more we can do and it's essential that we keep this momentum going.

Posts like Mike's belong in the annals of history. Stating, as Mike does, that Flash "is the bane of the Internet, and it needs to go away" is in no way constructive. In fact, it runs contrary to all the positive work that we've been trying to do in both the Flash and Web Standards communities in the last few years.

Flash is not going away. In fact, the Flash platform has more legitimacy today than it ever has ever had. And it's wonderful to see the Web Standards community engaging with us and working with us. Together, we can help educate developers on how to create standards-compliant Flash and work to improve the accessibility of Flash. And that's a very Good Thing for us all! :)

FlashAid version 1.0 released

Published on February 27, 2007 in Accessibility, ActionScript, Ajax, Flash, FlashAid and Javascript. 7 Comments

FlashAid logo

Executive Summary: FlashAid enables Ajax/JavaScript to find out if a user's screen reader is currently communicating with the browser and turn off the JavaScript functionality accordingly to make their sites accessible. It only works on Internet Explorer on Windows.

And now the full story...

I just released an update to FlashAid that, well, actually makes FlashAid useful.

You can see a live demo of FlashAid here.

(FlashAid only works on Internet Explorer on Windows. Make sure you have your screen reader on before testing.)

Version 0.1, the previous release, was a proof-of-concept that I hacked together after a talk with Jeremy. All it did was pass the value of the System.capabilities.hasAccessibility property from Flash to JavaScript.

The Adobe Flash docs for System.capabilities.hasAccessibility states the following:

A Boolean value that is true if the player is running in an environment that supports communication between Flash Player and accessibility aids; false otherwise.

What the documentation should state, is:

A Boolean value that is true if the player is running in Internet Explorer on Windows.

Essentially, that's all hasAccessibility appears to show. The Flash player uses MSAA to talk to screen readers but it only works in Internet Explorer (FireFox has MSAA support but the Flash player returns false for hasAccessibility on that platform, for example.)

So, the FlashAid proof-of-concept was essentially useless (you can check for IE on Windows with one line of code in JavaScript.)

Version 1.0, though, does have an important use. It's a one trick pony that communicates the value of Flash's Accessibility.isActive property to JavaScript. This one's useful because, on Internet Explorer on Windows, it tells you whether the user's screen reader is actually communicating with the browser.

Why is this important? Because it allows Ajax developers using progressive enhancement to detect whether the user is using a screen reader and turn off the Ajax/JavaScript functionality to allow these users to access their sites and applications.

Again, keep in mind that this only works for Internet Explorer on Windows but it's still an improvement on what was previously possible.

I hope you find FlashAid v1.0 useful.

SWFfix

Published on February 6, 2007 in Accessibility, Best Practices, Development, Flash and Standards. 0 Comments

What do you get when you combine Geoff Stearns (SWFObject) and Bobby van der Sluis (UFO)? A tireless superhuman SWF-embedding machine? Close! You get a new project called SWFFix that aims to be the panacea for the age-old problem of embedding Flash content in HTML pages in an unobtrusive and standards-compliant manner.

Read this ALA article by Bobby for great background on the problem and add the SWFFix blog to your RSS reader to keep up to date with the project.

Good luck, guys!

World Usability Day; Usability and Flash

Published on November 14, 2006 in Accessibility, Flash, Usability Design and Usability Testing. 0 Comments

Happy World Usability Day!

If anything, it should be painfully obvious to many of you why we need a day like this. Unfortunately, most of our industry still does not understand how to make usable products. Here's a quick five-point Dummy's Guide to Usability:

  1. Usability is not rocket science.
  2. Usability is not magic.
  3. Your product will not be usable because you tell your team it should be.
  4. Your product will not be usable if you think really, really, really hard about it.
  5. The only way to make usable products is to allocate a budget for it and involve the user throughout the development process.

OK, so it's really a one-point guide. Point 5 basically sums it up. It really isn't rocket science. So why do we get it wrong time and time again, project after project, company after company? Simple. Because we don't follow point 5.

If you're interested in reading more about all this, check out my earlier post, User interface design principles for web applications.

Take a look at what others are doing on World Usability Day and remember that usability doesn't apply just to the virtual world but to the devices around us in the tangible world too.

Flash Platform text resizing accessibility solutions mature

Published on September 29, 2006 in Accessibility, Community, Flash, Flash Platform, Flex, Open Source and Usability Design. 3 Comments

Bob Corporaal Text Sizing Demo

This has been a good week for Flash accessibility.

Bob Corporaal has a system that he is working on that gives Flash developers more control over how to react to browser text size preference changes.

At the same time, I noticed that the Flash Player doesn't work correctly with the browser keyboard shortcuts for the Increase Text Size and Decrease Text Size commands in various browsers. I documented the problem and presented a workaround on Monday, in my post, Making Flash movies obey browser text size changes.

Bob released a demo and source code for his system on Wednesday, with a blog post titled Browser Integration: Resizing Text. I commented there that the system was suffering from the same Flash Player issue I had run into and linked to the workaround.

Today, I read that Bob has updated his text resizing demo with the workaround I presented and the new system works like a charm. Find the updated demo and Bob's commentary in his post titled Resizing Text Headaches.

One of the things I love about open source, sharing and community is how ideas can take fruit and evolve at almost the speed of thought without any bureaucracy whatsoever. I think last week is a good case study in this. It also serves to underline the fact that there are people working on the Flash Platform who are passionate about accessibility and usability and who are working to improve things in a pragmatic manner. Won't you join us and help?

Obeying browser text size changes when using noScale

Published on September 26, 2006 in Accessibility, Flash and Flex. 6 Comments

In response to my previous post, Making Flash movies obey browser text size changes, someone asked in the comments whether this method works when Stage.scaleMode is set to “noScale” (like it is automatically in every Flex SWF, for example, and in many Flash applications.) Setting the scaleMode of the Stage to "noScale" lets Flash developers control the layout of a Flash application in response to a change in the size of the Stage. It's how you create liquid layouts in Flash.

The answer to the question is that, yes, this method will work when using noScale and you can decide exactly how to handle the layout of your SWF when the stage size changes.

Here's the example from the previous post, refactored with some custom scaling code: You can view the example online and download the source code.

Continue reading 'Obeying browser text size changes when using noScale'

Making Flash movies obey browser text size changes

Published on September 25, 2006 in Accessibility, Flash and Flex. 22 Comments

Flash movie obeying browser text size changes

John Dowdell discusses the Top Anti-Flash Cliches, a topic I revisit regularly under the guise of "Flash Myths". Of course, accessibility makes the list (specifically, the perception that Flash lacks any sort of support for it.) How timely, then, to see Niqui Merret post a very simple example that demonstrates how to scale a Flash Movie in response to text size changes in the browser.

If you use relative sizing for the text in your web pages (and you should), users can increase or decrease the text size to meet their personal visual requirements (FireFox: View → Text Size → Increase/Decrease). This is, of course, an essential accessibility requirement for users with poor eye-sight. Beyond that, however, it also benefits users with 20/20 vision who are in conditions of reduced readability due to environmental factors. I do most of my work on the road on my notebook computer and regularly find that increasing the font size makes sites easier to read when there is a lot of glare. The same goes if it's late and my eyes are tired.

The ability to change the size of text in web pages is a great accessibility feature but what happens when there is a Flash movie or application embedded in the page? By default, nothing at all. Changing the text size in your browser doesn't affect the Flash movie at all. This, of course, is not good. The Flash movie should grow or shrink in proportion to the text size change in the main HTML page so that text in the Flash movie is as easy to read as the text in the main page. Thankfully, Niqui has concocted a very simple way to implement this functionality using a combination of Bobby van der Sluis's UFO (or Geoff Stearns' SWFObject) to embed the SWF using progressive enhancement and JavaScript from Lawrence Carvalho and Christian Heilmann's Text-Resize Detection article from A List Apart.

Niqui's method scales the whole Flash movie in proportion to the font size change in the browser. This is a simple and effective method that doesn't require any changes to the Flash movie or any special architectural considerations. It is a method that will work with any existing Flash movie. As such, it is easy to implement and I suggest that we popularize it. As a first step, I would love to see UFO and SWFObject implement support for it.

The next step is to create a solution that provides developers with more control over responding to browser text size changes. This can be achieved by passing the text change event to Flash by using ExternalInterface. This way, Flash developers can listen for the event (say BrowserTextSizeIncrease and BrowserTextSizeDecrease) and respond to it. The major use case for this is to change only the size of the fonts in a Flash movie in response to browser text size changes (without scaling the whole interface or any images that might be in it.) Bob Corporaal is working on just a such a solution and will apparently be releasing the source for it soon.

In testing Niqui's solution and Bob's sample, I noticed that in FireFox on OS X, when the Flash movie is selected, you cannot use the ⌘ = shortcut in FireFox to increase the font size. I assume that the Flash Player is capturing this key combination and not releasing it to the browser (⌘ -, strangely, works.) The immediate workaround that comes to mind is to capture the key combination in Flash and then release it to the browser using ExternalInterface and increase the text size in response to this via JavaScript using a technique similar to the one presented by Bojan Mihelac in his article Power to the people: relative font sizes on A List Apart.

OK, so after writing the last paragraph, I actually went ahead and implemented it.

You can take a look at the result (click in the Flash movie before using the keyboard shortcuts to change the text size) and download the source.

The workaround uses Bojan's solution and isn't trivial to implement. It requires the creation of several style sheets and use of Paul Sowden's style-sheet switcher. Although not perfect, I haven't been able to find a neater solution for changing the text size using JavaScript.

It also appears that the behavior of the Flash Player with regard to this issue varies depending on the platform and browser that it is running on. Here is a brief summary:

Platform Browser Flash player behavior
OS X FireFox 1.5.0.6 Captures ⌘ =
OS X Firefox 2rc1 Captures ⌘ =
OS X Safari Doesn't capture either
OS X Camino 1.0.2 Doesn't capture either
OS X Opera 9 Captures ⌘ = and ⌘ -
Win XP FireFox 1.5.0.7 Captures ⌘ = and ⌘ -
Win XP IE 6 Captures ⌘ = and ⌘ -
Win XP Opera 9 Captures ⌘ = and ⌘ -

Update: I updated the above table with information for Camino and Firfox 2rc1, supplied by Bob Corporaal.

Note: Opera 9.0.2, especially on Windows, appears to have some issues with the text size keyboard shortcuts in general. Specifically, I can't use the + or Command/Ctrl + keys to increase the zoom level after reducing it.

The good news is that the workaround works on all of the above browsers/platforms. On Opera 9.0.2 under Windows, the Flash movie appears to lose focus after a resize and so you have to click on it again before using the keyboard shortcut. On Opera under OS X, I actually prefer the CSS-based scaling as opposed to the default zoom behavior in Opera.

The bad news is that the workaround isn't perfect. Specifically, mixing this workaround with the browser's default text size change feature can result in undesired behavior. For example, if you increase the font size all the way using the workaround (with the Flash movie in focus), then decrease the font size using the regular browser text change commands (with the main HTML file in focus) and then return to the Flash movie to increase the font size again, it will not work since the style sheet with the largest font size will already be selected with its text size reduced through the browser controls.

I'm going to talk with the Flash Player team at Adobe about this issue. I'm not currently sure whether they are aware of the problem (but knowing them, they probably are, so a solution may already be in the works.) In the meanwhile, this workaround will allow users to increase the text size of Flash movies that have focus using keyboard shortcuts.

Flashing at BarCampLondon

Published on September 4, 2006 in Accessibility, BarCampLondon, Best Practices, Community, Design Patterns, Development Process, Flash Platform, Flex 2, Usability Design, Usability Testing, Web standards and eXtreme Programming (XP). 2 Comments

Aral Balkan's Agile Development and Usability presenation at BarCampLondon.

BarCampLondon was a blast! Over the course of a weekend, I got to meet some amazing people, catch up with friends, learn some great stuff (including a new game called Werewolf) and get inspired. Big thank-yous to Ben Metcalf, Ian Forrester, Murray Rowan, and Paul Hammond for organizing the event and for your tireless omnipresence throughout the weekend. Similarly, thank-yous to Yahoo! UK, eBay, BBC Backstage, TechChrunch, Chinwag, and Belkin for sponsoring the event with food, drinks and network cables! And, of course, thank-you to everyone who attended for making the event what it was, for sharing and for lynching me so early in the game -- I wasn't a werewolf dammit! :)

My first session was titled Agile Development and Usability. It was a one-slide presentation in which I talked about the three big problems I see our field faced with today. Namely, a lack of understanding of development process, of the importance of the user and of application architecture. I followed this up with a high-level overview of solutions to these problems, including the use of Agile Development (with examples from eXtreme Programming/XP), User-Centered Development and usability patterns and pattern-based architecture. I ended the half-hour session with a brief glimpse into how these solutions can be implemented in projects for the Flash Platform using Flex 2, Arp and open source tools.

After my first session, I got a couple of requests for more information on Flex 2 and decided to hold a separate talk on just that subject on the second day. In that talk, I gave an overview of the Flash Platform, Flex 2 SDK and Flex Builder 2, using my Flex 2 Quick Starts for the examples.

In addition to presenting, I also got to attend quite a few presentations by other people. You can find notes from those sessions in the BarCampLondon category. Without fail, the sessions I attended were all highly engaging and informative. I can only surmise that the quality of the attendees and the BarCamp format had a great role to play in this.

You can find links to other media from the event on the BarCampLondon What Happened wiki page.

So, when are we going to have the next one? :)

BarCampLondon: Jeremy Keith on Hijax

Published on September 2, 2006 in Accessibility, BarCampLondon, Javascript, Usability Design and Web standards. 1 Comment

I'm sitting in Jeremy's session, hearing about his Hijax system for "progressive enhancement". Progressive enhancement takes a new look at what we used to call "graceful degradation". Basically, it's starting with the content/symantic layer and layering on additional functionality on top of that.

He's currently talking about how best to implement JavaScript behavior into your HTML application and the method he's showing me is so close (in intent and implementation) to the code behind method I advocate in Flex and Flash development.

The Hijax approach:

  • Begin using traditional page refreshes
  • Data sent to server via links and form submissions
  • Intercept (hijack) those links and forms using unobtrusive javascript
  • Send that to XMLHTTPRequest
  • Server returns just the information that's required

Server side requirements:

  • Back-end architecture must be modular
  • Web pages must be modular (components/APIs)

The paradox:

  • Plan for Ajax from the start
  • Implement Ajax at the end

When to use Ajax:

A page includes a form. When the form is submitted, the same page is returned with just part of the page updated (eg. blog comments.)

Clicking on a link returns the same page but with a different view on the data (on thing has changed.) Product ratings, filtered product set, etc.

Jeremy's method uses the XMLHttpRequest as a dumb waiter. Client-side processing is kept to a minimum.

« Older Entries

Bad Behavior has blocked 0 access attempts in the last 7 days.