Re: Regarding the accessible name calculation for aria-label within links?

James Teh,
Sailesh wrote: "I think it is necessary to draw a distinction between
elements like an
anchor, any form control vis a vis a div when it is a container for
other elements / content".
James response:
"Of course. My argument is that this distinction you speak of isn't
explicitly decreed by the spec. Nowhere does it unrefutably say that
the label should override the content in some cases and shouldn't in
others. It only talks about how it gets mapped to APIs. Therefore,
saying that NVDA doesn't comply with the spec is incorrect, because
this behaviour isn't specified in said spec."
Sailesh: Alright pardon me for saying NVDA does not comply or this is
a bug. Let me put it differently.
I believe, one needs to go back to basics. Leave the specs out for a moment.
Screen readers are assistive technology that primarily seek to
provide accommodation for their users navigate an inaccessible
environment.
So they might  perhaps render text next to a form field as  its label
even when it is not so marked up.
Sure it might be an incorrect guess, but it is the best when there's
no accessibility markup.

But before attempting to do this, assistive technologies should
interpret the accessibility markup as the specs suggest and expose to
the API.
Also, as a tool meant primarily for users with disabilities, the focus
should be on  rendering the best user experience possible to its
patrons in the circs.
So for instance, consider
Different title and anchor text:
<a href="#" title="Download PDF">Annual Report 2013</a>
Identical title and anchor text:
<a href="#" title="Annual Report 2013">Annual Report 2013</a>
Yes, the title becomes the accessible description and is rendered by
Firefox along with  the anchor text.
But NVDA should not render the title when it is the same as the anchor
text ... to help its users.
Sure developers need to be educated and not duplicate the anchor text.
But NVDA is an assistive technology and should fix this duplication to
help its user base.
So coming back to aria-label:
As it is intended to  trump anchor text, the aria-label should be
rendered by NVDA as it is exposed to FF as the accessible name.
And the aria-label and title both should be exposed in
<li>Aria label different from anchor text:
<a href="#" aria-label="Download PDF" title="2013 - Annual
Report">Annual Report 2013</a></li>
BTW, JAWS does this in FF and IE.
Thanks and regards,
Sailesh


On 2/13/14, James Teh <jamie@nvaccess.org> wrote:
> On 14/02/2014 5:05 AM, Sailesh Panchang wrote:
>> I think it is necessary to draw a distinction between elements like an
>> anchor, any form control vis a vis a div when it is a container for
>> other elements / content.
> Of course. My argument is that this distinction you speak of isn't
> explicitly decreed by the spec. Nowhere does it unrefutably say that the
> label should override the content in some cases and shouldn't in others.
> It only talks about how it gets mapped to APIs. Therefore, saying that
> NVDA doesn't comply with the spec is incorrect, because this behaviour
> isn't specified in said spec.
>
> Jamie
>
> --
> James Teh
> Director, NV Access Limited
> Ph + 61 7 5667 8372
> www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @nvaccess
>

Received on Friday, 14 February 2014 15:00:01 UTC