E-mail List Archives
Thread: Alt-text vs. Aria
Number of posts in this thread: 6 (In chronological order)
From: Maupin, Brennan Polaris McCaffrey - maupinbp
Date: Tue, Apr 02 2019 8:14AM
Subject: Alt-text vs. Aria
No previous message | Next message →
Hi all!
I have been looking at a website and have some questions regarding the use of alt-text vs aria, as well as aria's relevance in HTML5.
1) I have heard in the past that with HTML5, it is best to use HTML5 over ARIA whenever possible, and only use ARIA when necessary. It was mentioned that when used in incorrectly, ARIA can "break" a page more than fix it. Do you all have opinions on this? I have not been combing through html long enough to ever see ARIA "break" a page's functionality.
2) I am noticing that on the page I'm looking at, the developers have added wonderful alternative text to describe page elements that serve particular functions, but the elements themselves are not tagged in the way that I would (with aria attributes.)
For example, there is a navigation menu consisting of list of drop-down links and sub-links. The top level links have excellent alt-text attached to them explaining that they contain sub-links and how to operate them.
If I were designing the site, I would be inclined to use the "has-submenu" class and attributes to work better with a screen reader and in an effort to conform with 4.1.2 - Name, Role, Value.
My question is, is the alt-text method *incorrect*? It seems to essentially serve the same purpose, but I also feel like it does not conform to 4.1.2. Any thoughts on this?
-Brennan Maupin
From: Jeremy Echols
Date: Tue, Apr 02 2019 8:32AM
Subject: Re: Alt-text vs. Aria
← Previous message | Next message →
On point 1: I've seen sites where aria is used to set labels, but because devs never see or hear the aria labels, they get out of sync or copied and pasted. E.g., a form field has a placeholder of "search" but the aria label, due to a copy/paste error, says "user name". In the interest of making a design work, there's no proper label tag, and the aria label causes the field to make little or no sense.
On point 2: Typically a link doesn't have alt text, so I'm not sure to what you're referring. Is the link's text different for screen reader users than sighted users? This may be a red flag if so. Also, depending on the situation, having complex screen-reader-only text on a link can be extremely cumbersome. Additionally, if the site is using a custom widget that HTML doesn't provide, ARIA is the way to go. Menus and submenus have ARIA support if you build them with good JavaScript, as I recall, but that requires conforming to certain standards so that when the screen reader announces a thing is a menu, the user knows which keys activate which functionality. If it's all standard, you don't really need any explanatory text so long as ARIA and JS are built properly. For instance, I'm a fan of the approach detailed on the W3C site: https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html
From: Maupin, Brennan Polaris McCaffrey - maupinbp
Date: Wed, Apr 03 2019 7:32AM
Subject: Re: Alt-text vs. Aria
← Previous message | Next message →
Thanks so much for your input Jeremy.
On point 1: This example really clears up my confusion! Thank you for that.
On point 2: I also thought it was a bit odd to have alt-text attached to a link, but it is definitely there, and it is different from what sighted readers would be seeing.
I tried it with JAWS and found that you would hear the link role and link text per usual as you were navigating through, but then you would only hear the alt-text (e.g. "expandable, press space or enter to toggle...") *after* you had clicked on it.
The benefit I found when experimenting with the aria-haspopup="true" is that you hear the role of the link *before* the link is pressed. This is why I feel that the alt-text option really does not conform to 4.1.2 very well, but I'd welcome other opinions on the matter.
-Brennan
From: Jeremy Echols
Date: Wed, Apr 03 2019 11:36AM
Subject: Re: Alt-text vs. Aria
← Previous message | Next message →
As an aside, if the link can be activated by the spacebar or the enter key, and functions as activating a behavior rather than taking the user somewhere, I'd say it sounds a lot more like a button than a link. It may simplify things to just make those buttons - screen reader users will then need less guidance since they already know they can activate a button via space or enter.
From: joe
Date: Thu, Apr 04 2019 8:49AM
Subject: Re: Alt-text vs. Aria
← Previous message | Next message →
On point 1: 2.1 First Rule of ARIA Use
If you can use a native HTML element [HTML51] or attribute with the
semantics and behavior you require already built in, instead of re-purposing
an element and adding an ARIA role, state or property to make it accessible,
then do so.
From W3C: Using ARIA = https://www.w3.org/TR/using-aria/#rule1
From: Isabel Holdsworth
Date: Fri, Apr 05 2019 4:08AM
Subject: Re: Alt-text vs. Aria
← Previous message | No next message
Hi,
I'm not surprised that JAWS doesn't read alt text in links, as this
creates invalid HTML and the alt text may be rendered in different
ways, or perhaps not at all, depending on the browser. Alt text should
only be used in images.
ARIA is a great tool for making menus and other custom components
accessible. If it's done correctly, screenreaders will provide all of
the information their users need to understand and operate the
component.
ARIA can be over-used or incorrectly implemented. I've seen form
elements with <label> tags and also aria-label attributes. Sometimes
the aria-label content is the same as the <label>, other times it's
totally different. Either way, it can cause more harm than good and
needn't exist at all. I've also come across images that have both alt
and aria-label attributes, which is over-kill. Sometimes a role is
added to an element that natively has the same role. There's lots of
ways ARIA can be implemented badly, but used correctly it's a great
tool.
Cheers, Isabel
On 04/04/2019, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> On point 1: 2.1 First Rule of ARIA Use
>
> If you can use a native HTML element [HTML51] or attribute with the
> semantics and behavior you require already built in, instead of
> re-purposing
> an element and adding an ARIA role, state or property to make it
> accessible,
> then do so.
>
> From W3C: Using ARIA = https://www.w3.org/TR/using-aria/#rule1
>
>