Accessibility of Wikipedia, a March 2021 use test session
This page documents observations and outcomes from a user experience testing session of Wikipedia with a screen reader.
The test was conducted with the user Iran11y, under a FLOSS distribution using Orca as screenreader on March 22th 2021 on the French edition of Wikipedia. Iran11y relies on this solution for accessing the digital resources on a daily basis. So this session was an opportunity to better understand the state of Wikipedia accessibility from the experience of an user that actually require this topic to be well treated in order to have a good quality of interaction with the Wikimedia ecosystem.
This session was organized by user psychoslave after the release of the new talk page extention that led to a feedback discussion with Matma_Rex which involved the topic of accessibility. Thus the session to better evaluate the global state of accessibility of Mediawiki and the impact of this extension on this regard.
Observations
editFirst let's remember that this session was conducted with the help of Orca. Some issues might be specific to Orca, and complementary tests with other software solution could give a better idea of what is imputable specifically to Orca interpretation, and what is more a common assumption of most available screen reader. Nonetheless, real people out there are using Orca, and Wikimedia environment should deliver the best possible user experience for people who use it.
Browsing the article requires a user to go through the whole menu before the user can access the actual article content.
Footnotes disrupt the screen reader output. And as we know, Wikipedia articles comes with a lot of footnotes. That makes the process of consulting an article extremely impractical. No known palliative solution was reachable during this session. Two bypass approach have been tried:
- Using the printable version of the page, which didn't lead to any meaningful difference (and the feature is deprecated anyway).
- Copy/paste the content in a text editor. In one sense it improved the result, as the output flow would not be interrupted at each footnote reference. But on the other hand it made things even worse, as numbers glued to words were now interfering with the interpretation process. It could even go to the point where some statements on a date with a reference would be transformed to nonsense, like 1612⁴ becoming 16124.
Links that are in juxtaposition with punctuation make Orca pronounce this punctuation sign name out loud. This happens on Wikipedia when Orca is set to not pronounce punctuation this way, and on other websites this behaviour is not reproduced.
Regarding the content, and especially the content of talk page, there are issues that are not purely technical, as it pertains to how people express themselves in the interfaces. Issues on that side include:
- the use of emoticons. Not all emoticons are problematic though. Things like a unicode character (😀) might be properly interperted or ignored. Another technically fine way to deal with this kind of expression is to use templates such as
{{smile}}(
), with a properly set altattribute. Note that it is not fully the case of the just mentioned template at the time of writing: the attribute only provides the name of the file, which in this case is sufficiently clear to describe the idea, but is not that great in the utterance flow. - the use of of unconventional written forms. For example "1nsec" for expressing "1 nano-second".
- the use of idiosyncrasies, be it wikimedia-specific ones or more general practices. For example, multiple colons to represent depth of an answer in a talk page or the abundant use of acronyms. This later point is a wider accessibility problem in our community which can affect any user, although for screen reader users the issue is even more complicated as it mixes up with technical problems of interpretation. Specifically in the French community, but not limited to the Wikimedia projects, the practice has appeared over the last few years to mix both gender variety of nouns into a single term using a typographical midpoint. This is a practice guided by reasons similar to the use of the pronoun "they" as a singular alternative to "he" and "she" in the English world. So far this practice was rejected from article content, but users being free to express as they wish, can perfectly use this notational system in talk pages. While this remark doesn't question the legitimacy of the underlying claim behind this practice, it must be noted that such a practice hurts accessibility. Which is all the more a sad observation for an initiative which seeks to foster more inclusiveness.
The label "change the source" was not felt to be really relevant, as a meaningful way to convey the meaning "here is your way to reply to this talk". This label however is not always shown thusly, and for example with the new extension, the label "reply" is perfectly clear and appropriate.
Orca allows to set keyboard shortcuts to accelerate the browsing experience (jump to the next sentence, and so on). But when one tries to edit a wiki page, these shortcuts enter in conflict the form input actions. That is not an issue specific to Mediawiki here it seems, though. Disabling the shortcuts allows to edit the page text normally. But it requires changing the screen reader once again after editing to benefit again from shortcuts.
When consulting a diff, it's all but obvious what is going on. Visually, a lot of help is given that is lost in translation for screen reader users. Without going too deep on that point, for example there is a big plus or minus sign that are put alongside each paragraph presented in the diff. That signs lead to no utterance at all in the screen reader output flow.
Finally, with an important external guidance, the screen reader user was able to enable the new talk extension in its user preferences. That is, even with the help of someone with no disabilities who perfectly knew were to go, the step of enabling the extension was rather laborious. To be fair, enabling beta functionalities is not exactly the most important path to optimize on an accessibility point of view, but it nonetheless gives an indication of the journey that still must be made to achieve a good level of accessibility in the Wikimedia environment.
Thus said, the use of this extension appeared to be a great improvement of the user experience. To be honest, it's already the case for people who are already acculturated to Wikimedia talk page habits and customs and don't consult pages with a screen reader. No longer having to deal with colons is bliss, all the more with a screen reader. Minor issues were noted like the tab-order that will require quite some navigation before reaching the publish button, and the switch between rendered and source view was not clear for a screen reader user. Also the fact that the signature and the reply button are juxtaposed to the last paragraph was perceived as a source of confusion.
Recommendations for improvements on accessibility
editTo improve the browsing experience, the page might start with a single link "Go to the main menu", or possibly a second one "Go to the personal tools menu". After that, the article content should be the next accessed element through the tabulation navigation order. The opposite strategy can also be combined with this one: the first thing accessible through tabulation might be a link like "Go to the content". See the GNU Website for an example of page implementing such a practice. Note that this doesn't require any change on the visible interface. Links that lead to this menu can be hidden from users who don't require them, and the order in which tabulation browsing can be set independently from the HTML flow and of its visual rendering.
As a bypass solution to the problem of footnote references that disturb the output of Orca, it would be great to have an easily accessible version of articles that withdraws all links and footnotes references and keep only the "raw text", as one would read in a straightforward manner.
Regarding emoticons, several complementary approaches could be launched in the Wikimedia environment. All wikis should be populated with templates that allows to use emoticons that are well designed for accessibility. Campaign of communication to raise awareness of the existence of these templates and why it's important to use them rather than ASCII art or Unicode character alone should be launched after such a broadcast deployment. On a probably more long-term scale – as it would probably imply far more thought on software design development and integration – it would be even better to integrate a solution that guides more users towards good accessibility practices intuitively: triggering an emoticon menu combobox at colon input (:) is a rather common pattern in chat nowadays. This could be coupled with the previous approach, with the selection of an emoticon leading to output the proper template. Note that the rendered version of the new talk extension already includes a similar feature, with the arobase opening a dropdown list of users that one can notify.
Regarding Orca's shortcuts interference with page editing, most likely a bug report should be filled to the Orca team. Maybe a switch option already exists. But one should take into account that Iran11y has used this solution extensively for several years now, and during the session she went through option menus at a speed that is definitely not followable for a user who is not familiar with it. Surely it speaks for for the level of proficiency that this user has on this solution. So if a switch exists, it's accessibility is of discoverability should be increased. But, once again, here there is nothing that seems improvable on the Mediawiki side.
On the new talk extension, some thoughts might be given on how to optimize the tab path. Telling people that they are about to publish under a free license and give them links to this documents is certainly important. But having to pass through these links in order to arrive on the publication button is probably not essential. To be fair, yes, ctrl+enter do the job perfectly and directly since the edit box.
Creating an extension that would bundle user preferences that are optimized for screen reader users could be an approach that could be a mid term solution.