Accessibility is the developer's responsibility.
The web developer cannot know
which web browser his audience will be using, nor can he know, or even guess, what the client-side accessibility settings, CSS settings, Font settings, etc... might be.
To mitigate these unknowable variables, the web developer can simply take responsibility for all aspects of website development and delivery, including layout/design, UI, SEO, accessibility, alternate content, security, validation, error checking, etc...
To leave any of these aspects exposed to client side preferences is at best lazy, and at worst irresponsible.
Encapsulating these variables and addressing them within the architecture of the site is not a new development concept, but it generally requires the content to be loaded into an API separate from the web browser, which is itself a major variable.
This leaves only a
single client-side variable: is the plugin installed?
If true: load rich content.
If false: load alternate "generic" content.
Users without plugins installed, and biased developers, are kidding themselves; the web browser is nothing more than a container for online content.
There is no real "standard" beyond that which is minimally required to facilitate the display of content across platforms.
ie: the browser must support current HTML specifications. Period.
Plugin reality check:
- [Microprocessor]
Device composed of silicon, plastic and metal.
This device basically just opens or closes tiny little switches.
- plugin - [firmware chip].
Allows this device to communicate with RAM/HDD/keyboard/display by rapidly opening/closing the switches in a specific order.
- plugin - [shell]
Software that allows root level commands to be executed.
- plugin - [operating system].
Software "platform" installed on HDD allows to developers to write plugins that allow this device to browse/utilize other hardware/software plugins.
Proprietary; converts this generic device to utilize specifically designed software plugins.
ie: "Mac" or "Windows"
- plugin - [device drivers]
Proprietary plugins enable third party devices and more advanced functionality.
- plugin - [applications]
Proprietary software written for specific [operating system] plugins.
- plugin - [web browser]
Plugin for [operating system] allows user to connect to a wide area network and interact with generic standardized static content "HTML", regardless of platform.
Plethora of proprietary designs in use, none of which are identical in terms of content development and delivery.
Currently percieved as the foundation for all online content.
- plugin - [Quicktime]
Plugin for [web browser] allows users to view online content authored in the Quicktime format.
All major [operating systems] and [web browsers] are supported.
- plugin - [Real Player]
Plugin for [web browser] allows users to view online content authored in the Real Player format.
All major [operating systems] and [web browsers] are supported.
- plugin - [Windows Media Player]
Plugin for [web browser] allows users to view online content authored in the Windows Media Player format.
All major [operating systems] and [web browsers] are supported.
- plugin - [javascript]
Plugin for [web browser] allows users to view online content , mimicking [operating system] [application] behavior, within the [operating system] plugin [web browser].
This is the foundation for "web 2.0".
All major [operating systems] and [web browsers] are supported.
- plugin - [Flash]
Plugin for [web browser] allows users to interact with content authored in Adobe Flash/Flex.
All major [operating systems] and [web browsers] are supported.
At the end of the line, you have a concatenation of plugin architectures, each parasitically borrowing from their ascendants, that results in an interactive environment for user.
[Microprocessor]
[firmware chip] >
[shell]
[operating system] >
[device drivers]
[applications] >
[web browser] >
[Quicktime]
[Real Player]
[Windows Media Player]
[javascript]
[Flash]
Why does the Flash plugin in particular, represent a violation of this paradigm?
Think Different.