Being abe to convey type information certainly helps, but there seems to be a more fundamental disconnect between the job of a screen reader, for instance, and a truly rich, dynamic, custom application. Assuming that developers limit functionality to basic “bindows” style apps, then perhaps support for type-specific handling is all that’s needed, but for applications that don’t follow any predefined rules (e.g. truly custom applications), then type information isn’t enough. I’d expect there would need to be some way to convey arbitrary semantic and functional behavior and define AT-specific callbacks. However, programming anything more sophisticated than sparse metadata becomes intrusive to normal development, and this suggests that AT-aware applications might be better serviced via AT-specific custom applications rather than making one app serve two different interfaces.

Invariably, there will be interface modes that are incongruent with the natural and distinctive expectations of assistive technology.

Stairways are good interfaces for walking persons but ramps or elevators are more appropriate for wheelchair-bound persons.

To expect one interface to support radically different usages is inappropriate except for the most basic and simple of applications. Simple websites or applications constrained by basic types and behaviors may be accounted for via AT-aware type mappings, but beyond that, I doubt there is an elegant way to present arbitrary rich applications interfaces to incongruent audiences with metadata alone.

I think this is just being realistic. If two applications need to be written, they should be written instead of imposing an inauthentic approximation on developers that only addresses a small part of the overall problem.

So what do we end up with?

Instead of adding a element, we use a div with a role attribute that says it is a foo and not a div.

Then what happens next time something new is added? Use a div with a role attribute to say it is a foo and then a realrole attribute to say that its actually a bar. So that clients that support the new spec know its a bad, older clients know its a foo (which is close to being bar) and still older ones get a div?

Meanwhile we’re encoding the semantics of a document in multiple layers, which complicates authoring.

would love to see better javascript support in line-mode b rowsers like w3m and links, i know blind users who practically live in the emacs minibuffer, having a sort of commandline prompt to a web GUI operating a higher level would be useful..

Bindows components come with accessibility descriptions and instructions by default. In addition, developers can also create new accessible custom components or customize the built-in behavior to comply with various application specific requirements.

Bindows 508-compliant web applications still have the same rich Windows look and feel.
Checkout http://www.bindows.net/508/, try the accessibility tests and read about using Bindows to revamp existing web application or web page and become 508 compliant.

In short: much, much easier to support screen readers and other assistive technologies, and much, much better user experiences for those using them.

i.e. why role=”wairole:slider” and not <slider> or <wai:slider>?

You could still style it and script it to act as you want.

(Second attempt since I assumed this was a text input and the only clue otherwise is grey on grey text after

i.e. why role=”wairole:slider” and not or ?

You could still style it and script it to act as you want.