E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Bryan Garaventa
Date: Fri, Feb 22 2019 12:20PM
Subject: How to test the AccName algorithm dynamically using AccName Prototype
No previous message | No next message

Hi,
Since this comes up every now and again, usually with questions about what is or not expected in the AccName computation, I wanted to pass along the following live utility that helps to resolve this confusion, available at
https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html

This works by pasting whatever code you want to test into the editable field at the end of the page and clicking the Paste and Test button. You need to make sure that the root node that you want to compute the Name and Description properties for includes id="test" to identify which element is meant to be designated as the root node in accordance with the AccName spec.

This also includes the feature where, if you paste focusable elements like links and buttons or form fields into this and render them using the Paste and Test button, you can use Tab and Shift+Tab to move focus between them and the AccName computation will automatically be displayed for the currently focusable element no matter what the ID is set to.

The live algorithm being used here is the same one that is run from the W3C test case wiki to validate expected results, at
https://www.w3.org/wiki/AccName_1.1_Testable_Statements

As I continue working on edits for AccName 1.2, I will ensure to keep this live algorithm up to date with the latest updates as we hammer out the details of what AccName is meant to convey.
http://www.w3.org/TR/accname-1.1/

Visual ARIA, as referenced within the same page, also includes the same AccName algorithm, both of which will always be synchronized.

Since crowd sourcing is one of the most effective ways of identifying bugs, the more people who use this the better to make sure we haven't missed anything. Please pass along any issues and if found as part of the AccName Prototype, file them against the archive for this at
https://github.com/WhatSock/w3c-alternative-text-computation
Otherwise, if uncertain, file them against the AccName spec at
https://github.com/w3c/accname/
(Please review the currently open issues to be certain the issue hasn't already been reported for the 1.2 milestone)

All the best,
Bryan


Bryan Garaventa
Principal Accessibility Architect
Level Access, Inc.
= EMAIL ADDRESS REMOVED =
415.624.2709 (o)
www.LevelAccess.com

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Friday, February 22, 2019 5:41 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] aria-label vs alt text on linked images

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


According to the accessible name and description computation spec the alt text on an image inside a link with aria-label should not be announced.
aria-label overrides native HTML labeling (for a link with an image inside it that has an alt text, the alt text would be the native labeling in this instance).
So if you think of this as a single entity the aria-label should always be announced and the alt text ignored.
But if you think of this as two separate entities, the image separate from the link, then it makes sense that if you navigate to the image, as opposed to the link, that some screen readers may announce the alt text for the image.
I think a link with an image inside it should be treated as a single entity, but I am not sure if that interpretation is correct.
Authors can solve this dilemma by using one or the other, not both.
According to the spec, the alt text should be ignored in this situation.



On 2/22/19, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Patrick,
>
> It would be good if you could take an either-or approach and use only
> the alt or only the aria-label attribute. I'd personally go for the
> alt attribute on the image, as these have been kicking around since
> Methuselah was a sprog and are treated in much the same way by most
> browsers and screenreaders.
>
> Cheers, Isabel
>
> On 04/01/2019, Léonie Watson < = EMAIL ADDRESS REMOVED = > wrote:
>> The problem seems to be with specific browser and screen reader
>> combinations, coupled with the mode of interaction. A very quick test
>> using this example:
>>
>> <a href="https://example.com" aria-label="Example website"><img
>> src="example.png" alt="Example logo"></a>
>>
>>
>> With Jaws 2019 in Chrome, Firefox, and Edge; with NVDA in Chrome,
>> Firefox, edge, and IE; with VoiceOver in Safari on iOS; the -label is
>> announced however you focus on the link.
>>
>> With Jaws in IE, the alt text is announced however you focus on the
>> link; with VoiceOver in Safari on MacOS, the alt is announced if you
>> arrow onto the link, and the -label is announced if you use any other
>> mode of interaction.
>>
>>
>> This was a very quick test on a single instance of each combination,
>> so please treat the results on that basis!
>>
>>
>> Léonie.
>> On 04/01/2019 15:30, Patrick Follmann wrote:
>>> Thanks Steve, I appreciate your response and understand the question
>>> about why both are used.
>>>
>>> It was mostly just an experiment based on client feedback -- and we
>>> know that those of us who only heard the aria-label are using
>>> default settings on our screen reader software and the three of us
>>> have the same browser versions and we are all tabbing through the
>>> page to hear what is announced.
>>> I am not sure about the colleague who is hearing only alt text
>>> though, except I know he is using the same screen reader versions.
>>>
>>> Patrick
>>>
>>>
>>>
>>> On Fri, Jan 4, 2019 at 10:18 AM Steve Green
>>> < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> There are lots of reasons why this might happen, such as:
>>>>
>>>> Different methods of navigation, such as tabbing or virtual cursor.
>>>> Different behaviours in different versions of the same assistive
>>>> technology product. These are not usually mentioned in the release
>>>> notes so you only find them by experimentation.
>>>> Different behaviours between browsers.
>>>> Different configuration settings in the assistive technology.
>>>>
>>>> Why do you have an "aria-label" attribute if the images have "alt"
>>>> attributes?
>>>>
>>>> Steve Green
>>>> Managing Director
>>>> Test Partners Ltd
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf
>>>> Of Patrick Follmann
>>>> Sent: 04 January 2019 15:09
>>>> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
>>>> Subject: [WebAIM] aria-label vs alt text on linked images
>>>>
>>>> Hello,
>>>>
>>>> Some colleagues and I are getting different results when using
>>>> screen readers with linked image that have no link text but have an
>>>> aria-label attribute in the a tag and an alt attribute in the img
>>>> tag. (tabbing to the
>>>> image)
>>>>
>>>> One colleague is hearing screen readers (VoiceOver, JAWS and NVDA
>>>> with various browsers) read only the alt text. The rest of us are
>>>> hearing only the aria-label announced.
>>>>
>>>> What is expected behavior and why might we be getting different results?
>>>> We'd like to solve the mystery so we don't have conflicting results
>>>> in the future.
>>>>
>>>> Thank you,
>>>>
>>>> Patrick
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>> --
>> @LeonieWatson tink.uk Carpe diem
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.