Progressive Enhancement with Flash
by Armando Alves
- 4,059 views
How to make your Flash websites more accessible. ...
How to make your Flash websites more accessible.
The 7 habits of highly acessible RIAS and solutions to deploy alternate content with web standards while keeping your experience rich.
Post here: http://www.asourceofinspiration.com/2009/02/28/progressive-enhancement-with-flash/
Accessibility
Categories
Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Likes
- 5
- Downloads
- 106
- Comments
- 0
- Embed Views
- Views on SlideShare
- 3,728
- Total Views
- 4,059
Lance Pollard
Until then, most web development companies were doing what it’s called Graceful Degradation, focusing on the current technologies and offering a small support to older browsers. Back then, most of concerns were related to graphical browsers, with acessible experiences constrained by economical pressures.
Graceful Degradation
The website development was targeted for the latest browsers, with some backward support.
The main concern was to create a richer experience, with a high focus on presentation.
Progressive Enhancement
The focus here is on content, and no longer on presentaion for graphic browsers. The main concern is to assure the optimal distribution of content. In modern web development we should look forward, to other kind of displays and platforms.
But it does it a concern for all devices, starting with the least capable and walking all the way up to newer devices, enricheing the experiences but still separating presentation from information, with greater concern regarding acessibility and universal distribution, by using current web standards.
Another recent problem when deploying web applications based on the Flash Platform, is the increasing number of people using Flash blocking extensions, like Ad Block Plus.
And for those thinking that a 97% adoption rate of the Flash Player is enough, better think again, because amongst those 3% is one of the highest sources of traffic: search engines.
Another recent problem when deploying web applications based on the Flash Platform, is the increasing number of people using Flash blocking extensions, like Ad Block Plus.
And for those thinking that a 97% adoption rate of the Flash Player is enough, better think again, because amongst those 3% is one of the highest sources of traffic: search engines.
Another recent problem when deploying web applications based on the Flash Platform, is the increasing number of people using Flash blocking extensions, like Ad Block Plus.
And for those thinking that a 97% adoption rate of the Flash Player is enough, better think again, because amongst those 3% is one of the highest sources of traffic: search engines.
The main reasons to improve SWF searchability were the increasing amount of Rich Internet Applications, gadgets and games that were available to large audiences.
However, the indexation is pretty much limited. The bot algorithm works much like a real person, exploring the SWF file, clicking in buttons, inserting inputs and traversing on the multple states of the application.
For now, it only indexes text and URLs, and ignores images and dynamic content.
When first integrated by Google, it also didn’t supported Javascript embedding techniques like SWFObject, but recently that has changed with support for the most common embedding techniques.
Other limitations includes the lack of support for dynamic languages and deep linking.
The most problematic is still the absence of dynamic content indexing. With so many of RIAs and websites getting data from external sources, like XML files, a lot of the hidden web is still left outside, with no context whatsoever. And even if individual XML documents are indexed, they are mostly useless as they have no context and semantic value whatsoever, thus no help to search engines.
1) Content
From HTML 4 to XHTML with an eye to HTML 5, with support for device languages like WAP and XHTML Basic the content is deployed with langues with semantic capabilities
2) PresentationSecond, we add the presentation layer with languages like CSS1 and CSS2
3) Interactivity
While the previous 2 layers are presente on most devices and graphical browseres, interactivity is where the dreams and nightmares happen, and what i’l bet talking about.
We’ll try to deploy rich visual experience while keeping it available to the widest audience possible, with future compatibility also in mind.
1) Content
From HTML 4 to XHTML with an eye to HTML 5, with support for device languages like WAP and XHTML Basic the content is deployed with langues with semantic capabilities
2) PresentationSecond, we add the presentation layer with languages like CSS1 and CSS2
3) Interactivity
While the previous 2 layers are presente on most devices and graphical browseres, interactivity is where the dreams and nightmares happen, and what i’l bet talking about.
We’ll try to deploy rich visual experience while keeping it available to the widest audience possible, with future compatibility also in mind.
1) Content
From HTML 4 to XHTML with an eye to HTML 5, with support for device languages like WAP and XHTML Basic the content is deployed with langues with semantic capabilities
2) PresentationSecond, we add the presentation layer with languages like CSS1 and CSS2
3) Interactivity
While the previous 2 layers are presente on most devices and graphical browseres, interactivity is where the dreams and nightmares happen, and what i’l bet talking about.
We’ll try to deploy rich visual experience while keeping it available to the widest audience possible, with future compatibility also in mind.
1) Content
From HTML 4 to XHTML with an eye to HTML 5, with support for device languages like WAP and XHTML Basic the content is deployed with langues with semantic capabilities
2) PresentationSecond, we add the presentation layer with languages like CSS1 and CSS2
3) Interactivity
While the previous 2 layers are presente on most devices and graphical browseres, interactivity is where the dreams and nightmares happen, and what i’l bet talking about.
We’ll try to deploy rich visual experience while keeping it available to the widest audience possible, with future compatibility also in mind.
1) Content
From HTML 4 to XHTML with an eye to HTML 5, with support for device languages like WAP and XHTML Basic the content is deployed with langues with semantic capabilities
2) PresentationSecond, we add the presentation layer with languages like CSS1 and CSS2
3) Interactivity
While the previous 2 layers are presente on most devices and graphical browseres, interactivity is where the dreams and nightmares happen, and what i’l bet talking about.
We’ll try to deploy rich visual experience while keeping it available to the widest audience possible, with future compatibility also in mind.
1) Content
From HTML 4 to XHTML with an eye to HTML 5, with support for device languages like WAP and XHTML Basic the content is deployed with langues with semantic capabilities
2) PresentationSecond, we add the presentation layer with languages like CSS1 and CSS2
3) Interactivity
While the previous 2 layers are presente on most devices and graphical browseres, interactivity is where the dreams and nightmares happen, and what i’l bet talking about.
We’ll try to deploy rich visual experience while keeping it available to the widest audience possible, with future compatibility also in mind.
Web experiences don’t have to be dull, but they don’t have to be unaccessible either. We can have it both.
Instead of starting by building the rich experinece first, we’ll start with the basics. Content first. Then we add a presentation layer. And then, we apply the rich media and interactivity (Javascript, Flash).
It will be easier in the end, easier for maintenance at least.
We should have the basic functionality working without having to use the 3rd layer: If Javascript / Ajax / Flash aren’t there we should still be able to do basic actions.
Also, don’t forget where it’s going to be used: in a graphical browser we can use the TAB key to jump between inputs,but on a cellphone there’s no TAB key, so we should keep that in minf and add support for directional navigation with arrow keys.
Only add additional elements when it gets the experience richer.
So don’t add device specific events (onchange and onblur) unless you’re covered all others, so users don’t get frustated with your application on your device.
From screen resolution to conectivity it all affects how your application behaves.
For instance, on Ajax applications, you can use @include to bypass non graphic browsers.
Or use media target for stylesheets: print, mobile, screen.
From includes with conditional comments to external scripts, it will be easier to maintain the application and extending it when new technologies are available.