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).

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.

In T47891#4048692, @tstarling wrote:

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.

In T47891#4048692, @tstarling wrote:

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.

In T47891#4049901, @Graham87 wrote:

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.

• https://www.mediawiki.org/wiki/Help:Links?useskin=monobook#External_link_icons
• https://www.mediawiki.org/wiki/Help:Links?useskin=modern#External_link_icons
• https://www.mediawiki.org/wiki/Help:Links?useskin=timeless#External_link_icons

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

• https://en.wikipedia.org/wiki/Help:External_link_icons?useskin=monobook#External_link_icons
• https://en.wikipedia.org/wiki/Help:External_link_icons?useskin=modern#External_link_icons
• https://en.wikipedia.org/wiki/Help:External_link_icons?useskin=timeless#External_link_icons

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.

In T47891#4049828, @TheDJ wrote:

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.

In T47891#4049901, @Graham87 wrote:

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.

In T47891#4051452, @tstarling wrote:

In T47891#4049901, @Graham87 wrote:

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).