WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?

for

From: Chaals McCathie Nevile
Date: May 3, 2016 5:23PM

On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton
< <EMAIL REMOVED> > wrote:

> Deborah,
>
>
> I'm a big fan of your notion that WAI-ARIA functionality could be
> natively made available in the browser. That brings up what seems like
> the obvious missing key piece to truly ubiquitous accessible digital
> content development, which is standardized support for rich internet
> applications at the browser level. We already have a very well
> understood set of display and interaction conventions associated with
> how browsers handle old school HTML elements, such as radio buttons or
> links.

So the first issue here is that it isn't actually as well-understood as
you might think. There is quite a lot of magic in browser code, and the
people who wrote it can't always remember why they decided something 11
years ago - or went to work somewhere else on something else, or…

> I think we need a similar standardized playbook where browsers
> manufacturers are required to abide by a set list of display and
> interaction conventions that govern the user experience for the most
> common <div> powered widgets, prevalent types of dynamic content,
> and other advanced content constructs that are not currently natively
> supported at the browser level.

This is a *lot* harder than it sounds…

> Wouldn't it be great if a browser could do the "heavy lifting" involved
> with making, let's say, a tab panel accessible? With some very basic
> markup in place in the page source code, and maybe a little basic CSS,
> the browser would know how to handle things like input focus management,
> switching a tab's programmatic state and visible display, keystroke
> mapping, etc. in an automatic and standardized way that all users would
> be able to quickly understand and act upon.

Yep. There is even a spec that people are developing to try and make that
possible: https://discourse.wicg.io/t/panels-and-panelsets/1184

There are also at least two ways for browsers to present this stuff to
screen readers, through ARIA.

And yet, the interaction models - what keys or commands are needed and how
a given user can set those up for their particular environment - are still
basically a mess of dirty hacks that mostly work for most people most of
the time.

Which is a long way from being able to say "we got the accessibility story
right".

After a decade of serious work.

> Some might say it is a bit burdensome to require browser / user agent
> manufactures, not to mention operating system and assistive technology
> manufactures, to natively support access to modern digital content.
>
>
> I don't it is too burdensome at all. Consider that we are currently
> asking, actually requiring by law in many scenarios, individual
> site/app owners to do the "heavy lifting" and to develop accessible
> modern digital interfaces using what amounts to experimental poorly
> documented and erratically supported combinations of JavaScript, CSS
> and ARIA. And in addition to coming up with this coding wizardry on
> their own, content owners are supposed to magically arrive at a
> commonly accepted set of implementation standards (real code snippets)
> that will function consistently and facilitate adoption by the
> browsing public? Give me a break!

I agree with you that trying to push these requirements toward content
developers is moving in the wrong direction. It is important to work out
how to bring them toward browsers.

But it is also a very difficult task, and one that unfortunately many
people are prepared to ask others to work on without expecting that they
should themselves engage with the complexities and join th search for
solutions.

> Leaving the software manufacturers out of the accessibility
> responsibility equation really isn't working out that well, in my
> honest opinion.

I don't think they are left out, to be honest.

> I think that our regulators, legislators and some industry thought
> leaders have left the heavy lifting, in this particular case, to the
> wrong team. The centralized position of the software manufactures
> influence on accessibility, not to mention their economies of scale,
> makes them the right folks to drive this type of standardization of
> how rich content is handled, which will in turn raise energetic
> support in the accessible content development community and
> ultimately, will lead to widespread user acceptance.

I'm inclined to agree with some of this, and disagree with other bits.

Browsers and AT are, because of their relatively central position - in
particular because there are relatively few of them who need to get this
right - a good place to solve the problem. That's the sense in which there
is an economy of scale.

On the other hand, for some incredibly complex software that is called on
by millions of different people to handle millions of wildly different
tasks in wildly different situations, there are a very small number of
browser engineers on the planet, and a tiny number who have a reasonable
level of experience in accessibility.

Worse, as noted above, some serious part of that experience is pretty
painful, with all the lessons learned being that you can't just take what
someone tells you because they are a self-appointed accessibility expert,
and think it will work on a global scale, across the enormous diversity of
users and requirements they never even imagined.

> So, let's all get together some weekend, order some pizza and come up
> with a top 50 modern design patterns (I pick modals, what would you
> pick?), figure out a standardized way to accessibly code these chunks
> of content so that the OS/browser/AT chain will render the information
> in a way that facilitates functionality for users of all abilities?

I'll take user interaction - how you create an application with a set of
controls, communicate those to users, and connect them to things that user
can actually do effectively. My current thoughts on that are best
documented at
https://discourse.wicg.io/t/accesskeylabel-author-accessible-info-about-shortcuts/1392/2
and http://discourse.wicg.io/t/user-interaction-with-web-apps/1177 and
there is more thinking in the discussions around aria-kbdshortcut.

I don't manage to do so much on weekends, but I spend a lot of time most
weeks on the problems.

For things related to HTML, which is one *part* of the puzzle, we welcome
more people thinking about how to describe the problems accurately and
helping us imagine, test, reimagine, re-test, and maybe sometimes even
accept as done, real solutions.

> Wait a second, maybe that's not so good for job security as an
> accessibility specialist. That would make accessibility too easy.
> Never mind.

I'd love to believe we can get it done in a couple of years. But I'll bet
a lot of money that this isn't going to be a threat to the need for
accessibility specialists in the next decade. So there's not even a
down-side to trying :)

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
<EMAIL REMOVED> - - - Find more at http://yandex.com