E-mail List Archives
Re: Icon instead of text > open in new window
From: Birkir R. Gunnarsson
Date: May 15, 2017 1:04PM
- Next message: Jonathan Whiting: "Re: JAWS/IE reading aria-labelledby and aria-describedby"
- Previous message: Jeremy Echols: "Re: Icon instead of text > open in new window"
- Next message in Thread: Jeremy Echols: "Re: Icon instead of text > open in new window"
- Previous message in Thread: Jeremy Echols: "Re: Icon instead of text > open in new window"
- View all messages in this Thread
The title attribute maps to the element´s accessible description
property when it is not the source of the element's accessible name.
https://www.w3.org/TR/accname-aam-1.1/
Therefore it should be announced by assistive technologies in addition
to the element´s accessible name.
If it isn't, we need to file bugs with browsers and a.t. vendors,
until they fix it.
Announcing when an clicking an element opens a new tab or window is
not a WCAG 2.0 level A or AA requirement, as already discussed.
Now that we have a W3C specification that tells us how the title
attribute should be treated, we need to start respecting that
specification and make sure the vendors and the assistive technologies
do their parts, allowing the authors to use a convenient attribute
that should increase accessibility.
We can´t always tell authors not to do something that is proper use of
an attribute and according to spec, just because it is not supported.
Instead we need to ask ourselves why it is not supported and reach out
to those who are not supporting it.
If we discover reasons wy they technically can´t support it )e.g. a
title attribute on a non focusable element is hard to communicate by
any technology, because we don´t know the context in which it is used
or how users browser to it), we can change the spec.
If there is no reason (I think a title attribute on a focusable
element should always be exposed when that element receives focus), we
need to ask the vendors to support it.
I know this is a slight over simplification, standards and
technologies are complex, but I believe we need to do more to push
consistency between browsers and assistive technologies forward, not
always ask the authors to create workarounds.
The accessible name calculation standard is a huge step forward in
dictating how the title attribute should be treated, it was excellent
work! Now let's go ahead and take advantage of it.
Cheers
-B
On 5/15/17, Jeremy Echols < <EMAIL REMOVED> > wrote:
> Part of the problem is that it needs to be advisory information only, not
> information that makes the page accessible. The reason it needs to be
> unimportant text is that it may not be read by a screen reader. In testing,
> NVDA isn't reading a title on an <a> tag, nor am I able to see the title in
> Firefox unless I hover the mouse over it (keyboard focus isn't enough).
>
> From WebAIM again:
>
> "The title attribute is not read for most elements by default in most screen
> readers. Exceptions are the frame element and form elements that do not have
> a label. When a form element does not have a label, but does have a title,
> the title will typically be read. This approach, however, is often a misuse
> of title - if the title attribute is necessary to ensure accessibility of
> the form element, then it is certainly contains more than simply advisory
> information."
>
> If the fact that it opens externally is an important consideration for AT
> users, a title won't suffice. If opening in an external tab/window isn't
> important, then there's no need to put it in a title since AT users likely
> won't get that title anyway.
>
>
- Next message: Jonathan Whiting: "Re: JAWS/IE reading aria-labelledby and aria-describedby"
- Previous message: Jeremy Echols: "Re: Icon instead of text > open in new window"
- Next message in Thread: Jeremy Echols: "Re: Icon instead of text > open in new window"
- Previous message in Thread: Jeremy Echols: "Re: Icon instead of text > open in new window"
- View all messages in this Thread