E-mail List Archives
Thread: Using title attribute on non-anchor elements?
Number of posts in this thread: 20 (In chronological order)
From: Alex Hall
Date: Mon, May 02 2016 7:22AM
Subject: Using title attribute on non-anchor elements?
No previous message | Next message →
Hi all,
I have a results table showing what was pulled from a database query. I'm
using the title attribute on some th and td elements to, hopefully, show
some data when the user mouses over it. NVDA under Firefox doesn't seem to
indicate that this title is there at all, and I don't know if there's a way
to have it do so. Is this a shortcoming/bug in NVDA, or is using title on
non-anchors not recommended for conveying information to screen readers? If
the latter, what's a good alternative? Would using JQuery's onFocus to
populate a hidden div work, or is there something simpler? Thanks.
--
Alex Hall
Automatic Distributors, IT department
= EMAIL ADDRESS REMOVED =
From: Steve Faulkner
Date: Mon, May 02 2016 7:58AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
Hi Alex, use of title attribute is not recommended under most circumstances
for many reasons:
Refer to
https://www.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/
On Monday, 2 May 2016, Alex Hall < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all,
> I have a results table showing what was pulled from a database query. I'm
> using the title attribute on some th and td elements to, hopefully, show
> some data when the user mouses over it. NVDA under Firefox doesn't seem to
> indicate that this title is there at all, and I don't know if there's a way
> to have it do so. Is this a shortcoming/bug in NVDA, or is using title on
> non-anchors not recommended for conveying information to screen readers? If
> the latter, what's a good alternative? Would using JQuery's onFocus to
> populate a hidden div work, or is there something simpler? Thanks.
>
> --
> Alex Hall
> Automatic Distributors, IT department
> = EMAIL ADDRESS REMOVED = <javascript:;>
> > > > >
--
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
From: Paul J. Adam
Date: Mon, May 02 2016 8:12AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
Title only speaks as the accessible name or accessible description when placed on focusable elements like <a href> <input> <button>, image elements <img> or role=img, <iframe> elements.
I've never seen a screen reader speak the title on static text elements like <th> or <div> or <p>
Title will never appear visually to keyboard users, it only appears on mouse hover.
If you want to make a keyboard accessible tooltip you'll have to code it with JavaScript.
Easiest solution is to make the element with a title attribute focusable and then it will speak to the screen reader. But if the title info is important and needs to be conveyed to keyboard users then you'll need to make an accessible tooltip.
Would be nice if the browser developers would make their title tooltips keyboard operable by default!
Paul J. Adam
Accessibility Evangelist
www.deque.com
> On May 2, 2016, at 8:22 AM, Alex Hall < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi all,
> I have a results table showing what was pulled from a database query. I'm
> using the title attribute on some th and td elements to, hopefully, show
> some data when the user mouses over it. NVDA under Firefox doesn't seem to
> indicate that this title is there at all, and I don't know if there's a way
> to have it do so. Is this a shortcoming/bug in NVDA, or is using title on
> non-anchors not recommended for conveying information to screen readers? If
> the latter, what's a good alternative? Would using JQuery's onFocus to
> populate a hidden div work, or is there something simpler? Thanks.
>
> --
> Alex Hall
> Automatic Distributors, IT department
> = EMAIL ADDRESS REMOVED =
> > > >
From: Alex Hall
Date: Mon, May 02 2016 8:44AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
Thanks everyone, this is good to know. I hadn't considered that touch-only
browsers would be left out as well. I'll just add another column to the
table in this case.
If I make tooltips with CSS, tied to hover and focus so that touch browsers
can access them, what's a good way to expose the tooltip information to a
screen reader?
On Mon, May 2, 2016 at 9:58 AM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
wrote:
> Hi Alex, use of title attribute is not recommended under most circumstances
> for many reasons:
> Refer to
>
> https://www.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/
>
>
> On Monday, 2 May 2016, Alex Hall < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Hi all,
> > I have a results table showing what was pulled from a database query. I'm
> > using the title attribute on some th and td elements to, hopefully, show
> > some data when the user mouses over it. NVDA under Firefox doesn't seem
> to
> > indicate that this title is there at all, and I don't know if there's a
> way
> > to have it do so. Is this a shortcoming/bug in NVDA, or is using title on
> > non-anchors not recommended for conveying information to screen readers?
> If
> > the latter, what's a good alternative? Would using JQuery's onFocus to
> > populate a hidden div work, or is there something simpler? Thanks.
> >
> > --
> > Alex Hall
> > Automatic Distributors, IT department
> > = EMAIL ADDRESS REMOVED = <javascript:;>
> > > > > > > > > >
>
>
> --
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > > >
--
Alex Hall
Automatic Distributors, IT department
= EMAIL ADDRESS REMOVED =
From: Patrick H. Lauke
Date: Mon, May 02 2016 9:11AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
On 02/05/2016 15:12, Paul J. Adam wrote:
[...]
> Title will never appear visually to keyboard users, it only appears
> on mouse hover.
[...]
> Would be nice if the browser developers would make their title
> tooltips keyboard operable by default!
For what it's worth, both IE11 and Edge do this now by default.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Jonathan Avila
Date: Mon, May 02 2016 9:15AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
> For what it's worth, both IE11 and Edge do this now by default.
IE 11 does not do this for me by default. That is the tooltip does not appear when I tab to the link.
Jonathan
From: deborah.kaplan
Date: Mon, May 02 2016 9:23AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
On Mon, 2 May 2016, Paul J. Adam wrote:
> Would be nice if the browser developers would make their title tooltips keyboard operable by default!
It would be nice indeed if ubiquitous use cases which can only be
made accessible by knowledgeable developers using JavaScript wisely were
instead made natively available in the browser. It would also be nice if
WAI-ARIA functionality could be natively made available in the browser,
so, for example, something with a role=button would not require a
knowledgeable developer to add JavaScript in order to enable keyboard
functionality.
I keep being told this is a battle I will never win, so I should stop
asking for it. I'm not that kind of cynic, though. Browser
manufacturers can be convinced that having hundreds of thousands of
developers idiosyncratically coding their own solutions and JavaScript
is not nearly as good an idea as actually enabling this
universally-desired functionality in the browser.
I cannot believe that Tim Cook and Satya Nadella and Sundar Pichai have
stated, "No, we will never expose accessibility functionality in the
browsers for people who are not using assistive technology." Nor do I
believe that the accessibility teams at the browser manufacturers are so
opposed to improving accessibility that "we will never win this
argument" makes any sense.
Deborah Kaplan
From: Patrick H. Lauke
Date: Mon, May 02 2016 9:25AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
On 02/05/2016 16:15, Jonathan Avila wrote:
>> For what it's worth, both IE11 and Edge do this now by default.
>
> IE 11 does not do this for me by default. That is the tooltip does not appear when I tab to the link.
I've had a look, and can't find any special settings that I may have
enabled in IE11's settings. But it does work for me (in Windows 10 at
least, and from memory in Windows 8.1 too)
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Brooks Newton
Date: Mon, May 02 2016 2:11PM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
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
From: Paul J. Adam
Date: Mon, May 02 2016 2:23PM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
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 ADDRESS 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
>
>
>
>
>
>
From: Detlev Fischer
Date: Tue, May 03 2016 1:40AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
Weird - IE11 (11.0.9600.17842) does display title, but only on links (incl. linked images)
There is an offset of about a second before it appears which means you can easily miss it when tabbing through several links. The 'tooltip' does not scale along with browser zoom. And it only lasts for about 5 secs and then fades. Oh, and in some cases (depending on the position of the element and the page's scroll state), it is actually displayed outside the browser window far below the element - I guess this is a bug.
I have checked this on an alt and title test page that I have put together recently: http://www.3needs.org/en/testing/code/alt+title-test.html
--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg
Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
Patrick H. Lauke schrieb am 02.05.2016 17:25:
> On 02/05/2016 16:15, Jonathan Avila wrote:
>>> For what it's worth, both IE11 and Edge do this now by default.
>>
>> IE 11 does not do this for me by default. That is the tooltip does not appear
>> when I tab to the link.
>
> I've had a look, and can't find any special settings that I may have
> enabled in IE11's settings. But it does work for me (in Windows 10 at
> least, and from memory in Windows 8.1 too)
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >
From: Patrick H. Lauke
Date: Tue, May 03 2016 2:13AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
On 03/05/2016 08:40, Detlev Fischer wrote:
> Weird - IE11 (11.0.9600.17842) does display title, but only on links
> (incl. linked images)
I briefly tested it for links, for <span tabindex="0"> items, and for an
<input type="text">, and in all cases it displayed.
> There is an offset of about a second before it appears which means
> you can easily miss it when tabbing through several links. The
> 'tooltip' does not scale along with browser zoom. And it only lasts
> for about 5 secs and then fades. Oh, and in some cases (depending on
> the position of the element and the page's scroll state), it is
> actually displayed outside the browser window far below the element -
> I guess this is a bug. I have checked this on an alt and title test
> page that I have put together recently:
> http://www.3needs.org/en/testing/code/alt+title-test.html
Note that all those characteristics (the 1 second delay, the fact it
doesn't scale with browser zoom, etc) are just as true for mouse users.
i.e. this tooltip is the IE11/Edge standard tooltip.
With regards to not changing size relative to browser zoom: arguably the
tooltip is part of the browser UI, so I can understand why it would take
its sizing not from the current page content, but from the UI font size.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Patrick H. Lauke
Date: Tue, May 03 2016 2:14AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
On 03/05/2016 09:13, Patrick H. Lauke wrote:
> With regards to not changing size relative to browser zoom: arguably the
> tooltip is part of the browser UI, so I can understand why it would take
> its sizing not from the current page content, but from the UI font size.
Also worth noting that the same is true for tooltips (triggered with the
mouse) in Chrome and Firefox too, so it's not a quirk/shortcoming of
IE/Edge alone.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Detlev Fischer
Date: Tue, May 03 2016 4:51AM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
Points taken! When I said "only displays tooltip if title is on links" I didn't mean to imply that it would not display on other focusable elements - just that it does not seem to work if title is put on an img element within a link. Looks like it generally works when title is directly placed on focusable elements (incl. span with tabindex=0).
--
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg
Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
Patrick H. Lauke schrieb am 03.05.2016 10:13:
> On 03/05/2016 08:40, Detlev Fischer wrote:
>> Weird - IE11 (11.0.9600.17842) does display title, but only on links
>> (incl. linked images)
>
> I briefly tested it for links, for <span tabindex="0"> items, and for an
> <input type="text">, and in all cases it displayed.
>
>> There is an offset of about a second before it appears which means
>> you can easily miss it when tabbing through several links. The
>> 'tooltip' does not scale along with browser zoom. And it only lasts
>> for about 5 secs and then fades. Oh, and in some cases (depending on
>> the position of the element and the page's scroll state), it is
>> actually displayed outside the browser window far below the element -
>> I guess this is a bug. I have checked this on an alt and title test
>> page that I have put together recently:
>> http://www.3needs.org/en/testing/code/alt+title-test.html
>
> Note that all those characteristics (the 1 second delay, the fact it
> doesn't scale with browser zoom, etc) are just as true for mouse users.
> i.e. this tooltip is the IE11/Edge standard tooltip.
>
> With regards to not changing size relative to browser zoom: arguably the
> tooltip is part of the browser UI, so I can understand why it would take
> its sizing not from the current page content, but from the UI font size.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >
From: Jonathan Avila
Date: Tue, May 03 2016 1:12PM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
> I briefly tested it for links, for <span tabindex="0"> items, and for an <input type="text">, and in all cases it displayed.
This seems to work for me on Windows 10 with IE 11 but not Windows 7. What version of Windows did you use?
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!
From: Patrick H. Lauke
Date: Tue, May 03 2016 1:53PM
Subject: Re: Using title attribute on non-anchor elements?
← Previous message | Next message →
On 03/05/2016 20:12, Jonathan Avila wrote:
>> I briefly tested it for links, for <span tabindex="0"> items, and for an <input type="text">, and in all cases it displayed.
>
> This seems to work for me on Windows 10 with IE 11 but not Windows 7. What version of Windows did you use?
From earlier in the thread:
> it does work for me (in Windows 10 at least, and from memory in
Windows 8.1 too)
I believe this was a system-wide change in Windows starting with 8.1
(first spotted it in some Metro/Modern apps I audited on 8)
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Chaals McCathie Nevile
Date: Tue, May 03 2016 5:23PM
Subject: Re: Behaviour being triggered by ARIAUsing title attribute on non-anchor elements?
← Previous message | Next message →
On Mon, 02 May 2016 16:23:59 +0100, < = EMAIL ADDRESS REMOVED = > wrote:
> On Mon, 2 May 2016, Paul J. Adam wrote:
>
>> Would be nice if the browser developers would make their title tooltips
>> keyboard operable by default!
>
> It would be nice indeed if ubiquitous use cases which can only be
> made accessible by knowledgeable developers using JavaScript wisely were
> instead made natively available in the browser.
Yes.
> It would also be nice if WAI-ARIA functionality could be natively made
> available in the browser, so, for example, something with a role=button
> would not require a knowledgeable developer to add JavaScript in order
> to enable keyboard functionality.
Indeed. I have spent some time working on this, talking to e.g. W3C TAG
about it, and so on…
> I keep being told this is a battle I will never win, so I should stop
> asking for it. I'm not that kind of cynic, though. Browser
> manufacturers can be convinced that having hundreds of thousands of
> developers idiosyncratically coding their own solutions and JavaScript
> is not nearly as good an idea as actually enabling this
> universally-desired functionality in the browser.
Quite.
Although, as always, it turns out that we need to explain the problem, not
the solution. Trust me - I've got that horse and cart backwards on this
very question, multiple times.
In particular it turns out that if we trigger the behaviour *from ARIA*
there are likely implications for backwards compatibility that mean
browsers will never go there.
But being able to attach the important pieces of behaviour more easily
than having to write an entire script would be great.
In particular, the idea that content developers should be trying to write
the User Interface in javascript strikes me as mad - there literally isn't
enough capability in the platform for a developer to know what the user
needs and is capable of doing, in order to successfully produce an
accessible user interface for those who don't happen to fit the "dominant
paradigms".
> I cannot believe that Tim Cook and Satya Nadella and Sundar Pichai have
> stated, "No, we will never expose accessibility functionality in the
> browsers for people who are not using assistive technology." Nor do I
> believe that the accessibility teams at the browser manufacturers are so
> opposed to improving accessibility that "we will never win this
> argument" makes any sense.
In my experience you are quite right about this. However it is the case
that if accessibility teams who mostly work on a software application like
a browser don't understand the particular problem, they're unlikely to
accept a solution on faith - most of them have been down too many
dead-ends from doing that and are rightly concerned to invest their
precious resources where they will bring the most return.
So we need to make the argument, and we need to make it clearly and well.
My own efforts are somewhat flawed, but I'm happy when people build on
them or help me do so - as indeed Deborah has over the years.
cheers
Chaals
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com
From: Chaals McCathie Nevile
Date: Tue, May 03 2016 5:23PM
Subject: Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?
← Previous message | Next message →
On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton
< = EMAIL ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
From: Jonathan Cohn
Date: Wed, May 04 2016 7:13AM
Subject: Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?
← Previous message | Next message →
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 ADDRESS REMOVED = > wrote:
>
> On Mon, 02 May 2016 21:11:07 +0100, Brooks Newton < = EMAIL ADDRESS 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 ADDRESS REMOVED = - - - Find more at http://yandex.com
> > > >
From: Brooks Newton
Date: Wed, May 04 2016 2:27PM
Subject: Re: Browsers handling more widgets nativelyUsing title attribute on non-anchor elements?
← Previous message | No next message
Hi Chaals,
Thank you for taking the time to address my response to Deborah's comment about her desire for browsers to natively handle some of the WAI-ARIA functions. I know most folks on this thread just check in to find answers on "in the weeds" issues like, what browser supports this or what attribute works best for that. However, I think from time to time it's good to raise our heads up out of the weeds and take a gander at some of the bigger questions on the horizon that drive our industry. So thanks for engaging me and the others on this broader topic.
Quick note about my background: I've been a professional in the Web business since 1998, having served worked in the U.S. in public schools, state agencies, private business (Web design agency owner for a dozen years), plus I've worked as the accessibility lead at what was the fourth largest company in the world, as well as having served as principal accessibility consultant for one of the big agencies in the U.S. and have served as a consultant for several other a11y agencies you likely interact with on a daily basis in your committee work. I also make a pretty good pan of baklava. You can ask Birkir about that.
Believe you me, I have a distinct understanding of the complexities involved with getting accessibility to work well for people of all abilities. You can also ask Birkir about that, as well. I certainly don't have as a clear of an understanding as you have, but enough to be conversant in this context. I have significant experience transferring theoretical accessibility knowledge to real people who need real solutions to do their work accessibly in the digital trenches as web/software production team members. That's why I'm shocked that so much emphasis has been placed on site owners and their designers and developers to get accessibility right on their own, without the strongly regulated support from the operating system, user agent, and assistive technology manufacturing industry. Granted, I'm no lawyer. However, I've studied U.S. accessibility regulatory law - and let me tell you, there is a glaring absence of guidance for the software industry, when compared to the burdens that have been unloaded on site/app owners in this country.
I'm sure you have done so, but for others on this thread, take a look at the provisions of the laws that exist in the U.S. and across the globe that govern web accessibility. U.S. laws or laws-in-progress, such as the Twenty First Century Communications and Video Accessibility Act (CVAA), the Section 508 refresh, and the ADA refresh go out of their way to exclude from obligations the three types of software manufacturers that have such as strong bearing on the ultimate accessibility of web/app based digital content. I'm not guessing about this just to have something to say or posturing for Internet karma. I've been on the hook to figure this out for some of the largest organizations on earth. And let me tell you, it is a darn impossible task to achieve accessibility without strong support from the software technology that we all depend on to get web and app data from the ether into our brains. Any others on this thread who feel the same way? Let your voices be heard as a follow-up on this thread. Better yet, let the U.S. Department of Justice know how evolving accessibility law should be handled by directly responding to the call of comments that will soon be forthcoming as part of the new ADA SANPRM.
I've personally trained thousands (no exaggeration) of web site developers, writers, designers, information architects, rich media developers, business owners, quality assurance / user acceptance testers and c-suite executives on the ins and outs of digital accessibility. I have also personally consulted with dozens of the world's biggest companies on how to make their digital content more accessible. I've watched this industry mutate into its current state, which frankly, seems farther from the goal of universal access than it was 10 years ago. The answers being offered by those "in the know" for questions that arise out of frustration at how to make complicated digital interfaces accessible are increasingly technically obfuscated solutions that invariably involve lopping more responsibilities onto the site / app owners plate. Is that really the right direction? Look man, if we can't get site owners to write decent alt text, how are we going to get them to custom script complex interaction patterns, state switching, focus management, etc. for a bevy of JS-powered widgets they thought were plug and play ready to go? As they say in the U.S. South, I think I'm preaching to the choir here...not much need for additional persuasion on this point. These site owners need some help from software manufacturers in making standard and automatic many of accessible accommodations that are required to make rich Internet applications accessible.
Chaals, I have a tremendous amount of respect for the work you and others have completed, in terms of evolving markup, defining standards and serving up resources to help folks make their content accessible. No complaints, only praise for that work. I am, however, deeply frustrated at how much of a gap exists between theoretical accessibility and actual accessibility. And, I think the majority of where that gap lies now has a lot to do with the fact that too much is being asked of site / app owners and their design and development teams, and not enough is being asked of the software manufacturers.
I don't think the W3C WAI or other voluntary standards bodies have left software manufacturers out of the mix. I never said that. What I said is that legislators, regulators and some industry thought leaders have left them out of the mix. In my opinion, we will never see a groundswell of support for digital equality unless all of the relevant forces at play are required by law to do their respective parts. Software provided by OS/UA/AT manufacturers is very relevant to digital accessibility. It must be regulated to harmonize the efforts we are demanding of digital content owners.
So, as Sarah kindly pointed out in her post yesterday, we are going to get another chance to chime on how U.S. digital accessibility law gets shaped as part of the new Supplemental Advanced Notice of Proposed Rulemaking (SANPRM) that has just been issued by the United States Department of Justice.
http://www.ada.gov/regs2016/sanprm_statement.html
This supplemental piece to the ADA relates to government agency obligations. This is particularly interesting, in terms of how we the people might be able to get our government to commit to holding software manufacturers to a high standard modern accessibility support. Let's speak up on this and other issues critical to driving universal access of digital content. We've got a chance to do this in the coming weeks as part of the ADA SANPRM public comment process.
Over and Out,
Brooks Newton