W3C home > Mailing lists > Public > public-low-vision-a11y-tf@w3.org > March 2016

RE: conflicting ARIA functionality

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Wed, 16 Mar 2016 17:17:29 +0000
To: "Rochford, John" <john.rochford@umassmed.edu>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Message-ID: <BN1PR03MB2688BC7137D3CE893B85CC09B8A0@BN1PR03MB268.namprd03.prod.outlook.com>
John, I have a few thoughts on the topic of ARIA and low vision.

*        This issue that is raised is similar in one aspect to speech users as they may not know what text to voice in order to activate the link.  Dragon does seem to compensate and can allow for the link text to be voiced or the accessible name.

*        An issue comes up with the accessible name for images - browsers' without plug-ins don't show this information and so users with low vision may not have access to the alternative text for an image.

*        One ARIA attribute that does seem to be used by screen magnifiers is aria-activedescendant.   This is used for proper focus tracking on composite controls.

On an un related note I see they also have an alt on the text link which is not a valid attribute AFAIk.


From: Rochford, John [mailto:john.rochford@umassmed.edu]
Sent: Wednesday, March 16, 2016 10:16 AM
To: public-low-vision-a11y-tf
Subject: conflicting ARIA functionality

Hi All,

I recently received interesting feedback (below), from an employee of AI Squared, about implemented ARIA functionality in which it is unclear what to do for blind users as well as low-vision users. Should we take action about this and, if so, what?

"Please keep in mind that I am not a coder.  However, it seems that ARIA should provide a consistent UX for both blind and sighted people as much as possible.  As an example of where I think this currently has issues is on our home page.  If you navigate to aisquared.com, you will find three links, which are all called "Learn More."  Obviously, "learn more" doesn't bode well for screen reader users because it is ambiguous and especially not useful if the user is navigating by link.  Thus, we have ARIA labels for these links.  You can see the code below:

<a title="Learn More About ZoomText" class="button" aria-label="Learn More About ZoomText" href="http://www.aisquared.com/products/zoomtext/" alt="Learn More About ZoomText" data-gtmlabel="ZoomText" data-gtmaction="Home Product Highlight" data-gtmcategory="Cross Promotion">Learn More</a>

This way, a blind user can hear what the item refers to, rather than simply hearing "learn more."  The problem comes into play when we are trying to figure out what we should speak.  For ZoomText Magnifier/Reader, we will read what is on the screen.  For ZoomText Fusion, we use the ARIA spec and read more than what is on the screen.  Of course, this may be challenging for low vision users because we only highlight "Learn More" while there is actually more speech that is being spoken.  However, a low vision user would never see that text because it doesn't exist on the screen.  Some of our technologies default to reading both because we don't know which one to read.  That may make the user think the technology is failing or be very annoying at the least.  The blame then falls to the AT, when in reality, the issue is that the standards just aren't clear on what to do.

In a perfect world, we would have web designers who would never need ARIA labels for links, but unfortunately, the world is not perfect. <smile>"


John Rochford
UMass Medical School/E.K. Shriver Center
Director, INDEX Program
Instructor, Family Medicine & Community Health
Twitter: @ClearHelper
[Facebook Button]<http://www.facebook.com/pages/New-England-INDEXShriver-CenterUMass-Medical-School/227064920160>[Twitter Button]<https://twitter.com/NEINDEX> [WordPress Logo] <http://www.disabilityinfo.org/blog/>
Received on Wednesday, 16 March 2016 17:18:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:23:18 UTC