WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Icon instead of text > open in new window

for

From: Jeremy Echols
Date: May 15, 2017 2:07PM

Okay, let me see if I'm reading this correctly. I'm not trying to be obnoxious here, I just don't see how the title can do what you say. I am in agreement that you don't need to announce external pages; at this point I'm just trying to make sure I understand how titles are meant to be handled.

According to https://www.w3.org/TR/wai-aria/roles#link, a link gets its name from content or author. This means a link follows all rules in https://www.w3.org/TR/wai-aria/roles#textalternativecomputation. The link doesn't have aria labeling, so 2A doesn't get triggered. It's not going to trigger 2B as far as I can tell, as it's just a simple link and not some form of widget. 2C appears to apply, as the link role allows "nameFrom: contents ". 2C seems to push for looking at children of the node in question, which triggers rule 3, which seems to me to say that it will use the text, "Facebook" as the accessible name. Rule 2D, which uses the title, will not apply because a suitable accessible name was already found: "The last resort is to use text from a tooltip attribute (such as the title attribute in HTML). This is used only if nothing else, including subtree content, has provided results."

The rules for computing accessible description and accessible name appear to be the same (other than description using aria-describedby if present), so the name and description in this case would both be "Facebook". I can forcibly change the description with an aria-describedby attribute, but not title, as it is only used if the rest of the calculations produced nothing.

Testing in NVDA and Firefox, I see the behavior I expected: "Facebook visited link" when using a title, or "Facebook visited link blah blah blah" when referring to an element via aria-describedby.

I believe this is correct behavior, and not a bug in the browser or screen reader.