WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan Cohn
Date: May 4, 2016 7:13AM

I personally think of "role=" as a interim state and not a good way to specify components. Just as role="Navigation" can be handled with a Nav tag, I think that models that are using non-native tags should be regularly evaluated and determine how to transition the role= attribute into a standard that can then have proper tags created.

Since I have not developed much HTML though perhaps I am just dreaming the impossible dream.

Best wishes,

Jonathan



> On 3 May 2016, at 19:23, Chaals McCathie Nevile < <EMAIL REMOVED> > wrote:
>
> 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
> > > >