Wikipedia:Wikipedia Signpost/2013-09-04/Technology report
Technology report
Making 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 post by Denny 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.
- Wiki Loves Monuments Android app fixed: Yuvipanda has fixed the Wiki Loves Monuments mobile application for Android.
- 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".
Discuss this story
Accesibility
Random page
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://wiki.riteme.site/w/index.php?title=Special:RandomInCategory&category=String_instruments. --NaBUru38 (talk) 06:15, 7 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]