Google Chrome Falls Short on Accessibility

This week Google announced the launch of Chrome, an open-source browser project based on existing Webkit rendering engine. Features include tab-based browsing, a simple-yet-extensible interface, a newly integrated search mechanism, and dedicated processing containers for complex Javascript applications. But what about accessibility?

Reports from message boards indicated that despite many impressive under-the-hood improvements, Chrome falls short of providing an accessible browsing experience for users with disabilities. On their respective blogs, David Bolter wonders about WAI-ARIA support and Steve Faulkner of the Paciello Group questions a number of missing features:

Limited support for keyboard input
No support Windows high contrast mode
Lack of programmatic clues for interface elements
Information describing links or focused elements not interpreted by screen readers

Reports are that Google has begun to work on conveying information through Windows Accessibility APIs and newly-drafted WAI-ARIA support for future releases. Which is fine. The question remains why accessibility continues to be considered an “add-on” feature set, rather than a priority considered necessary for beta implementation.

If Google truly wants to create an accessible browsing experience, they might want to take a clue from the creators of Firefox who continue to support and advance their advocacy for universally designed users.

About this entry

You’re currently reading “Google Chrome Falls Short on Accessibility,” an entry on AniktoBlog

Published:: 09.06.08 / 10am

Category:: Technology, WAI-ARIA, Web Accessibility

About Anikto LLC

Named after the Greek word for “open,” the purpose of Anikto (ah-NEEK-toh) is to explore and develop barrier-free digital experiences through speaking engagements, published articles and client deliverables.

Anikto operates under the core principle that truly innovative and highly utile media benefits all users, while exceeding primary objectives benefits stakeholders and organizations.

Rob 09.06.08 / 11am

Much as I hate to say this, as a software developer, things like this are often seen as an addon for two driving reasons

1) Development is focused around the needs of the *developer*, and experiences the developer has. My brother is (severely) handicapped, and to some extent that affects the way I think about software design. Not all people work like that.

2) The *majority* of people (speaking wholistically, not about subsections of the population) are not handicapped, therefore the design goes for the majority

3) Not enough people who do have these issues realise that they need to raise them with the original developer/manufacturer to get their voice heard.

Kel Smith 09.06.08 / 6pm

Thanks, Rob. I would add as 4) that many organizations don’t make accessibility a priority in their business plan. As a result, project engagement leads don’t factor this into the equation when writing functional requirements documentation. Too often, spec is written to accommodate a combined skillset competency rather than users’ needs.

Many thanks for contributing to the conversation.

I tried Google Chrome: It’s light. fast and Rocks: By Olga Lednichenko « Olga Lednichenko -My new Slate 09.09.08 / 8am

[...] Google Chrome Falls Short on Accessibility [...]

Google Chrome Falls Short on Accessibility

About this entry

3 Comments

Have your say

About Anikto LLC

Recent Entries

Categories