RE: conflicting ARIA functionality

John,

I was just checking this out and noticed other things about the AI Squared page that would be just as concerning:
1) Tabbing order does not follow visual displayed order for the top of the page items as it starts at the Sitecues A>A component and progresses leftwards
2) The expand and collapse items in the middle of the screen do not announce their state or state change
3) Once one is expanded, I cannot collapse it, I can only expand another but never get them all collapsed again
4) I do not see a good focus indicator around any of the four Learn More buttons, or About Us, Contact Us or Find a Dealer green buttons 
5) The News from AI Squared links all have titles that repeat the entire link
6) The input field next to the Subscribe button does not announce any label or instructions when focus is put in it via tabbing
7) Focus order on the social media icons is left to right and not the visual left to right order
8) The social media links open new windows but do not tell the user/screen reader so

For the Learn More buttons/links for low vision users, perhaps you could just move the Learn More buttons up directoly below the section labels that they are located in. (The library Learn More would need a heading for it to work the same way)
Since all the aria and other text ideas are to add to the understanding of the context of the Learn More buttons, why not just add more text within the button itself. 

This is a low technology solution that designers often overlook.

I have used that method with great success.
 
For example: Learn More about Libraries, Learn More About ZoomText, Learn More about sitecues, Learn More about Window-Eyes, 

Regards,

Alan

Sent from Mail for Windows 10

From: Rochford, John
Sent: Monday, March 21, 2016 10:42 AM
To: Jonathan Avila; public-low-vision-a11y-tf
Subject: RE: conflicting ARIA functionality

Hi Jonathan,

Thank you for that great feedback.

I will share it with the AI Squared employee.

John

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] 
Sent: Wednesday, March 16, 2016 1:17 PM
To: Rochford, John <john.rochford@umassmed.edu>; public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>
Subject: RE: conflicting ARIA functionality

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 unrelated note I see they also have an alt on the text link which is not a valid attribute AFAIk.

Jonathan

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? 

:: BEGIN QUOTED TEXT ::
“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>”
:: END QUOTED TEX ::

John

John Rochford
UMass Medical School/E.K. Shriver Center
Director, INDEX Program
Instructor, Family Medicine & Community Health
http://www.DisabilityInfo.org
Twitter: @ClearHelper