Techshare Keynote – Richard Schwerdtfeger

My Overview

I’m putting up my notes from the talks I saw at Techshare 2009, and Richard Schwerdtfeger‘s was the first. Please note that this is what I picked up, not direct quotes. [My comments in square brackets.]

Richard is a Distinguished Engineer from Accessibility Strategy and Architecture, IBM, and his talk took us on a journey from the early days of software accessibility, through to tomorrows outlook. Some things I’d heard about before, but it was great to hear about it from a first hand source.

The text from the presentation has been published.

Richard’s Talk

Working in accessibility is a difficult space, like King Sisyphus pushing the boulder up a mountain. But with persistence, we can move things forward. (Pic of poodle pulling over parking meter)

Early Days

In 1990, screen readers could read the DOS buffer. But when going to the Graphical User Interface (GUI), the fear of loosing computer access completely was huge.
For some people, this would mean not being able to work, or not able to keep in touch with friends.

The ‘Windows of Vulnerability’ article written about this, but a small group at IBM research were working on the problem (Jim Thatcher was part of the team), and they built a GUI screen reader.

The writer of the article tried it, and thought it was so good that they should tell everyone. The follow up article was called ‘Making the GUI talk’.
Before this there was nothing, no JAWs etc.

In those days, the methods were based on reverse engineering the semantics of the GUI, which led to inaccuracies. There was no direct API. [This parallels the current lack of application semantics in HTML at the moment.]

In 1995 Microsoft released ‘Active Accessibility’.

We learned what was needed to create accessible applications: I.e. what if the application told you what was needed, rather than what you backwards engineered.

At this time we still needed an off-screen model to recreate the interface for screen readers.

In 1998, the Java accessibility API was released.

This was the first cross-platform API that allowed access to rich text, with no reverse engineering.
It formed the foundation for accessibility for the next decade (e.g. Iaccessible2, Linux’s accessibility model, etc.)

Unfortunately, it didn’t co-inside with what was happening on the web.

The early web years

In 1999 WCAG 1 was released. At that time we were dealing with static documents, and seeing new content always meant reloading the page. We tended to focus on tab and click. You could make websites accessible, but the desktop and web were still very different. It ran in parallel with desktop space, with different people working in each domain.

In 1994 [2004?], I (Richard) was asked to lead accessibility in software [ for IBM?]. The industry was experiencing a shift to Web 2.0 type sites.

For IBM, this shift was a big deal as we do middleware and services.

But how people created the Web 2.0 sites was through the use of CSS & JavaScript. It didn’t address the interoperability issue with HTML, and when writing WCAG 1 we didn’t know how to solve this problem (i.e. things had to work without Javascript).

This was shooting ourselves in the foot, because a rich experience can be more usable for everyone.

The accessibility for HTML was dependant on the HTML semantics, but HTML 4 is not fully keyboard accessible, as only links and forms are keyboard navigable.

This was a major disaster waiting to happen. Compliance with accessibility meant not being as usable as it should be.

Another problem was that new components had no means of providing information to the ATs. Examining this, I (Richard) thought that we need to add desktop capabilities to HTML.

Vendors had other things to do (e.g. security), and accessibly was being pushed to the back burner.
Therefore IBM went to the open source community, and hired Aaron Leventhal and (someone else) and started creating an open community, [I think he mentioned Dojo?], and centred around selling web 2.0 applications.

Industry wide adoption has made ARIA one of the biggest things happening in the accessibility world.

Web Applications

It adds to HTML (before going to the browser and AT) that enables a richer and more flexible accessibility API.

Note that WCAG 2 talks about being robust, i.e. interoperability. You are really leveraging the browser to do a lot of work.
We found a great deal of acceptance amongst engineers at IBM.

ARIA:

• Brings the accessibility and usability of the desktop to the web.
• Allows for full interoperability with AT.
• The technology to meet WCAG 2.

Challenges:

• The switch between WCAG 1 & 2.
• Testing tools needed.
• Web becoming more programmable (mashable).

For example, instead of worrying about a single page that you write, it might be created using widgets, or RSS etc. These things are drawn into a webpage, rather than ‘authored’ in the traditional sense.

Mashups (such as those that use Google maps) can create problems, but people are going to re-use those widgets because they are hard to create.

The future

To fix these, we need to step outside of one size fits all model.

Accessibility needs to become a preference [scripting enabled came to a similar conclusion last year].

IMS GLC/ISO Access for all – standards[?] are moving to the mainstream.

• Resource capability matched to preferences.
• User prefs integrated with device prefs.
• HTML5 local storage could be used to store these preferences.[Could it? I thought it was per-site, like cookies.]
• W3C personalisation roadmap: ubiquitous information.

The web is an open pipeline to the masses.