Page MenuHomePhabricator

External link icon for file extensions should have alt text
Closed, DeclinedPublic

Description

External links show an icon, but no alt text is rendered. This should be added for accessibility.


Version: unspecified
Severity: enhancement

Details

Reference
bz45891

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:30 AM
bzimport set Reference to bz45891.
bzimport added a subscriber: Unknown Object (MLST).

Might be a WONTFIX, see T4443 comment 15

See this relevant discussion:
http://en.wikipedia.org/wiki/Help_talk:Citation_Style_1#format_PDF_in_the_Template:Cite_journal.2Fdoc_examples

I've changed the summary to be more specific, now that I've realised exactly where external icons are used:
http://www.mediawiki.org/wiki/Help:Links#External_link_icons

Alt text for them would be far more useful for screen reader users such as myself when they're used to denote file extensions, especially PDF files.

Note that there is now only one external link icon; however, as this is a background image it can't have an alt text set on it, so this isn't a trivial change.

Bug 54604 is a discussion on restoring icons.

As laid out here, adding new functionality to the external links (marked by a background-image in Vector) for assistive technology doesn't bring advantage (no enhancement) to users.
@Jdforrester-WMF I would recommend to close this as INVALID if no new inputs are given within a certain time frame (30 days).

TheDJ changed the task status from Open to Stalled.Nov 9 2017, 2:16 PM
TheDJ subscribed.

I do think that this is a reasonable request. There is a also ticket for indicating MIME type of a link destination for accessibility purposes: https://github.com/w3c/aria/issues/484
We could of course start generating title attributes for links like these, and then automatically add " - PDF file" to that title attribute. That might be a valid work around, but it would add further complexity to the parser of course.

I'm however of the opinion that the entire topic of external links requires attention from browser/screenreader vendors.. Same as browsers now do CORS checks, a screenreader should basically inform you when leaving the CORS sandbox.. But that's too much complexity to fix on our side I think.

tstarling subscribed.

If the icon is conveying information then it is a violation of WCAG 2.0 SC 1.1.1 "Non-text Content" if we do not provide a text equivalent. The only way out of this is to claim that it is "pure decoration", which I don't think is true.

Using CSS background images to convey information is discussed in WCAG note F3.

Adding a title attribute explaining that the link is an external link, similar to the title attribute for red links, would probably be sufficient for conformance, although it's not clear to me whether screen readers will actually speak the title attribute.

Adding a title attribute explaining that the link is an external link, similar to the title attribute for red links, would probably be sufficient for conformance, although it's not clear to me whether screen readers will actually speak the title attribute.

Nope, they wouldn't. Alt text on the icon would be the best option here.

If the icon is conveying information then it is a violation of WCAG 2.0 SC 1.1.1 "Non-text Content" if we do not provide a text equivalent. The only way out of this is to claim that it is "pure decoration", which I don't think is true.

While in principal, that might seem true, I partly disagree with that. You see, the target of the link IS being communicated to the screenreader and If I remember correctly, a screenreader can easily be triggered to read out the target url. As such, by knowing the target url, you can interpret if the link is 'external/internal' if you want, so the basic information IS being communicated, it's just not 'enhanced'/'sped up' the way we do with a little symbol in a page view.

I think we also need to consider that our interface and content has a very high density on interaction and information. To me this is one of those things that falls under: Yes, ideally you want to communicate all this information and hints to a screenreader user. But at the same time overflowing and over saturating people with this information is ALSO an accessibility issue and we need to find the desirable balance between this.

So. yes, for Wikipedians the distinction between an internal link and an external link is important enough to add a visual hint. But I doubt many incidental wiki users note or understand the meaning of the icon. It's a distinction that almost no other website in the world tends to make... Even worse, some browser vendors have started hiding the link target even when hovering the link. It's also not a distinction that screenreaders tend to make. So while information, how valuable IS the information 'in flow', considering that at it's core it sort of already is available to the screenreader user.

Nope, neither NVDA or JAWS can read out the target URL. But it doesn't really matter anyway. with the regular external link icon. I'm more concerned about links to files like PDF's ... but it seems they don't get any special treatment now for sighted users either.

Nope, neither NVDA or JAWS can read out the target URL. But it doesn't really matter anyway. with the regular external link icon. I'm more concerned about links to files like PDF's ... but it seems they don't get any special treatment now for sighted users either.

ZOMG.. how the hell did no one fix this yet ??? It seems that JAWS only has a 'identify same page links" option (default on). NVDA seems to rely on the hoverstate triggering the reading of the browsers statusbar, but that seems broken in all browsers that they support according to themselves :)..
Sigh...

For VoiceOver it's VO-shift-U btw. to read the target of a link.

Note that a few skins still include specific icons for various links. On Wikimedia wikis those are Monobook, Modern, and Timeless. E.g.

Also, there is a more complete list of link types at Enwiki (in the third column of this table). E.g.

Within those, Monobook and Timeless appear to use the same configuration and icons, but Modern has unique icons for everything except PDF and it has additional icons for news: links and for https links (both of which Vector used to have: screenshot).
For reference, the icons were removed from Vector in 2014 after much discussion in T56604: Large number of CSS rules for external links

Like @TheDJ (my interpretation, correct me if wrong) I see the right handling of links mainly as part of the software vendor's requirements.

While in principal, that might seem true, I partly disagree with that. You see, the target of the link IS being communicated to the screenreader and If I remember correctly, a screenreader can easily be triggered to read out the target url. As such, by knowing the target url, you can interpret if the link is 'external/internal' if you want, so the basic information IS being communicated, it's just not 'enhanced'/'sped up' the way we do with a little symbol in a page view.

In WCAG language, you are saying that the href attribute is the text alternative. I suppose that would be allowable since WCAG sets a low bar as to what is a text alternative. It doesn't specifically mention the href attribute. The fact that it is practically inaccessible, as Graham87 says, would not affect WCAG compliance.

I'm more concerned about links to files like PDF's ... but it seems they don't get any special treatment now for sighted users either.

On the English Wikipedia, PDF links get a special icon in all skins, due to MediaWiki:Common.css. Wikipedia:Manual of Style/Linking states that it's not necessary to give the file type in the link text for PDFs since the icon is sufficient.

Sighted users have the option of reading the URL, which is displayed at the bottom of the window on hover, but most users don't read it. English Wikipedia policy is to put the file type in either the link text or an icon, reflecting the poor usability of requiring users to read the URL.

I'm more concerned about links to files like PDF's ... but it seems they don't get any special treatment now for sighted users either.

On the English Wikipedia, PDF links get a special icon in all skins, due to MediaWiki:Common.css. Wikipedia:Manual of Style/Linking states that it's not necessary to give the file type in the link text for PDFs since the icon is sufficient.

Related ARIA ticket: https://github.com/w3c/aria/issues/484

Do T47891#4049983 and T47891#4051387 imply that this is a WONTFIX (declined) on the MediaWiki side, as it's up to screenreader applications to provide "same site" functionality? Or what is a feasible way to proceed?
Asking as tickets shouldn't remain stalled for too long (three years in this case).

In response to @Aklapper, it doesn't seem like a risk-free way to proceed here. TheDJ has filed a GitHub issue on ARIA repo, which has been tagged with target ARIA 2.0. That's due 31 Dec 2022. It doesn't seem feasible to outsmart browsers in the meantime, if the protocol is a different one, that's browsers/screenreaders business to expose this appropriately.