Images have missing or insufficient alternative text

[selfthinker]

Some images have missing or insufficient alternative text. That will make them inaccessible to screen reader users.
That fails 1.1.1 Non-text Content.

• The alternative text of images that link to their detail page don't describe their target. The default way DokuWiki renders images is by adding a link around it that links to its detail page. Screen readers read the title of the link which the system sets to its filename in its namespace (for example, 'wiki:dokuwiki-128.png'). That is not very helpful.
  If an image is decorative and linked, it should describe the target. If it is meaningful and linked, it should both convey that meaning and describe the target. If an image is added with the ?nolink option, then it is completely up to the author to give it an appropriate alt text. But when it is linked to its detail page by the system, authors cannot do anything to prevent bad alternative text (which includes the title in this case).
  I would recommend to prepend the title with something like "Details about image:".

Here is a demo of how NVDA reads out the linked images on the syntax page:

linked-images-nvda.mp4

• The alt text of the emoticons aka smileys is not sufficient. When using the default verbosity settings, many of them are not read out at all by screen readers. Some are only partially read out. NVDA only reads some of the characters one by one. VoiceOver actually pronounces some. (The ones it pronounces as smileys are: 8-), :-) and ^_^ as "smiley", :-( as "frown", :-O as "surprised" and ;-) as "wink". It only partially pronounces the rest character by character.)

Here is a video of how NVDA reads the smileys:

smileys-nvda.mp4

I wonder if it's time to either drop the smileys altogether because most modern devices have an emoji picker of their own. Or make them entities that are swapped with their emoji equivalent. That would make the syntax backwards compatible. Modern screen readers are pretty good at reading emojis. They usually read the text as defined by the CLDR (Unicode Common Locale Data Repository).

• The inline SVG icons for the user and page tools should be marked as decorative (via aria-hidden=true). Some screen readers would not ignore it otherwise. While you're at it, I would also add focusable=false to prevent IE focusing on it.

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" aria-hidden="true" focusable="false">

• Links within the content (except wiki links) have background icons whose meaning is not available in text. That's especially interwiki links, but also external and email links, etc.
  This could be fixed by adding the interwiki shortcut string into the link title, although a full word would be much better. For example, [[wp>Wiki]] could have the title of "Wikipedia".
  

• The alt text for the first footer badge is not the same as the text on it. The text on the image says "CC PD" and the alt text says "Public Domain". The alt text needs to at least include the same visible text so that speech recognition users can target the links easily. Using Dragon and saying "click CC PD" or "click PD" does not click on the badge without it. I suggest to change the alt text to "CC PD - Public Domain". (The other badges have text on them which is not always the exact same as the alt text. That's not a fail because they have the same meaning and all words on the images are repeated in some way in the alt text.)
  That fails 2.5.3 Label in Name.
  

Other non-fail accessibility issues

These don't strictly fail WCAG but are minor issues.

• The footer badges are always linked but the alt text doesn't describe the target. That's more a usability than an accessibility issue because the target will also be ambiguous to seeing users.

• When resizing text in Firefox, the link icons don't get bigger. That will make their context harder to understand for people with low vision.