Making Wikipedia more accessible: In this week's "Technology report", we explore ways of making Wikipedia more accessible to users of screen readers. Graham87 is a highly active contributor who is also blind and accesses the site through a screen reader.
ByAdam Cuerden, Graham87, and Kirill Lokshin
In this week's "Technology report", we explore ways of making Wikipedia more accessible to users of screen readers. Graham87 is a highly active contributor who is blind and accesses the site through a screen reader. We asked him to suggest ways in which editors could help make Wikipedia more accessible:
Compared with many websites, Wikipedia generally works very well with screen readers. It was the third-most popular site in a 2008–09 survey involving over 1,100 screen reader users. It has a consistent "look and feel", and guidelines encouraging the judicious use of headings and links make it more accessible. However, there are a few important things that editors can do to make Wikipedia articles easier to read for users of screen readers:
Avoid separating list items by blank lines, especially in bulleted lists, as it makes lists harder to read with screen readers. For example, this list of tips to make articles accessible contains three items, and would be read by a screen reader like this: "list of 3 items, <text of the list> ... list end". If there were a blank line between each list item (i.e. if I had pressed the enter key twice between each point), it would be read out like this: "list of 1 items, <text>, list end; list of 1 items ..." and so on.
Keep everything in its expected location in terms of wiki markup (the text in the edit window). Most modern screen readers will read text in Wikipedia in the order it's presented in the wiki markup rather than its physical position on the screen; therefore a screen reader user's experience is disrupted if items are not in their usual place. For example, if a template that changes the position of the table of contents like {{TOC right}} is placed above the lead section of an article (in terms of the wiki markup), a screen reader user who is used to going straight from the table of contents to the first heading with a single keystroke will miss the text of the lead section.
Use alt text to complement image captions. Alt text, which is produced using the "alt=" parameter in the image markup, is read out by screen readers but is not usually visible to sighted users. It is especially handy for images that contain useful features that are readily apparent to those who can see the image (e.g. a cartoon caption, a sign, a graph with an easily identifiable pattern). There is no need to note these features in the image caption because most people will be able to see the image, but screen reader users should also have access to them where possible.
For more information on accessibility in Wikipedia, both for screen reader users and people with other usability issues, see the accessibility guideline. Signpost readers may also be interested in WikiProject Accessibility, which always welcomes new members. Questions or concerns about accessibility may be raised at the project's talk page.
VisualEditor enhancements
Copy-paste improvements continue: The VisualEditor team continued to make improvements to the tool's copy-paste functions, aiming to support copying of any richly-formatted text into VisualEditor, with appropriate markup being applied automatically. The team hopes to eventually allow direct copying from Wikipedia pages not currently open for editing.
Rapid typing bug fixed: A bug where very quick typing or input editor use could cause VisualEditor's text to become corrupted has been fixed.
Wikidata news
How do we measure the quality of Wikidata?: A blog postbyDenny Vrandečić asks this question and proposes several possible metrics.
Using Wikidata to support Wiktionary: An analysis of how Wikidata might support the Wiktionary model has been presented. Since a dictionary is essentially a structured set of data about words, Wikidata could be an excellent fit; however, significant effort is still required to define a specific data structure to be used.
URL datatype: Wikidata defines numerous data types for the various kinds of data entered into it. For example, the page on Brassica oleracea includes categories of information such as "genus", which is of the type "item", meaning that the genus also has a Wikidata page; and "image", which is of the type "Commons data file", meaning that it links to a file on Wikimedia Commons. A new "url" data type is currently being tested; once complete, it will allow Wikidata to provide ready-made links to external reference materials.
VIAF: Gerard Meijssen has written a series of posts on VIAF, an inter-library system for matching different methods of organising library records on individual people, and how Wikidata uses it for information. Topics covered by the series include a general overview of VIAF and how the system deals with deletions from the database.
In brief
Wikipedia Signpost Android application:Yuvipanda has created an Android application to notify users of Signpost updates and allow reading of Signpost articles from mobile phones. The application is available through Google Play.
New HTML tag support: The <wbr> tag, which inserts an optional mid-word linebreak, is now supported.
Random page tool for categories: The new Special:RandomInCategory tool allows users to visit a random page in a category. The tool currently includes subcategories—but not their contents—as "pages in a category".
Talking of visual accessibility, I'd like to talk with some editors who have different levels of vision impairment, to learn what system/browser settings they use, and what other software they frequently find helpful. Things like screen-magnification levels, specific fonts, copying text into alternate text-editors, custom style-sheets, and everything else. I've started a thread at WikiProject Accessibility#Visual impairment, listing what I can find, and would appreciate any comments, or assistance in finding the relevant editors (please nudge anyone you know of who might help). Thanks! –Quiddity (talk) 06:40, 7 September 2013 (UTC)[reply]
Afaik we still have no guidelines on what needs to go into an alt caption. There was a big push to include them in all FAC candidates, and elsewhere, a few years back, which collapsed when it appeared we had no reliable guidance on what type of information was needed (does anybody have a link to those discussions; I remember several alternative texts for a photo of Kings College Cambridge for example). The question is not simple. Johnbod (talk) 13:50, 9 September 2013 (UTC)[reply]
I'd presume they should provide a brief description of what the photo is. @Graham87: What do you think? Adam Cuerden(talk) 13:57, 9 September 2013 (UTC)[reply]
Cool feature! I'd love to have an option to check for subcategories as well. By the way, you can make a direct link like this: https://en.wikipedia.org/w/index.php?title=Special:RandomInCategory&category=String_instruments. --NaBUru38 (talk) 06:15, 7 September 2013 (UTC)[reply]
Thanks for the tip! :) --NaBUru38 (talk) 15:30, 12 September 2013 (UTC)[reply]
Visual Editor
Copy and paste of richly formatted text has had a history of causing numerous problems for me. The people at the Computing Reference Desk have never been able to explain these problems. Same for people at email services who tried to help me.
If Visual Editor had become mandatory I would have either left Wikiepdia or been accused of frequent vandalism. Plain text is the only thing I can handle.— Vchimpanzee· talk·contributions· 20:18, 9 September 2013 (UTC)[reply]
Still, for what VisualEditor is, copy-pasting of richly formated text is, if not a necessity, fairly near. As this is the technology report, we report on where major code updates are happening, which mainly means VisualEditor, not Wikitext. Adam Cuerden(talk) 22:13, 9 September 2013 (UTC)[reply]
Twitter
LinkedIn
Reddit
Digg
+ Add a comment
Discuss this story