WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using title attribute on non-anchor elements?

for

From: Paul J. Adam
Date: May 2, 2016 2:23PM

Well native HTML controls like <button>, <select>, <input typeÚte>, <input required>, etc. should be made screen reader and keyboard operable by the browser/OS manufactures.

I'm not quite sure if browsers should add keyboard behavior to any element it finds with a role like role=button, I would think if you put role=button on a <div> then the developer is responsible for adding keyboard behavior.

So for native elements the browser and OS should take care of the accessibility but for custom ARIA controls I think the developer must be responsible for accessibility of that widget since they are the creator of the look, feel, functionality unlike native controls which are more restricted.

I'm all for making a11y as easy a possible! title attribute is a bit different because that's a HTML4 attribute displayed by the browser/OS.

For <dialog> tags those should really be accessible by the browser and OS, whereas role=dialog should most likely be handled by the developer.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On May 2, 2016, at 3:11 PM, 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. 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.
>
>
>
> 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.
>
>
>
> 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!
>
>
>
> Leaving the software manufacturers out of the accessibility responsibility
> equation really isn't working out that well, in my honest opinion.
>
>
>
> 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.
>
>
>
> 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? Wait a second, maybe
> that's not so good for job security as an accessibility specialist. That
> would make accessibility too easy. Never mind.
>
>
>
> Brooks Newton
>
> Independent Digital Accessibility Consultant
>
>
>
>
>
>