Wikipedia:Wikipedia Signpost/2013-11-06/WikiProject report

This week, we spent some time with WikiProject Accessibility, a project that strives to make Wikipedia accessible for users with disabilities. The project improves Wikipedia's guidelines and Manual of Style, collects useful templates and scripts, and provides support to impaired Wikipedians. We interviewed Graham87, Paul MacDermott, John Carter, and TheDJ.


 * What motivated you to join WikiProject Accessibility?
 * Graham87: I'm totally blind and use a screen reader, so accessibility issues directly affect me. Therefore it was logical that I would join the WikiProject once it was established. Before that time I had helped shape the accessibility guidelines, and pointed out accessibility issues throughout Wikipedia.
 * Paul MacDermott: I am visually impaired and use a screen magnifier to enlarge text to a readable size, so am also affected by accessibility issues. I found the project a couple of years ago after looking to see what help might be available on Wikipedia when I started to encounter problems as I attempted more difficult editing tasks.
 * John Carter: Having seen a number of editors who have on their user pages courageously indicated that they have some form of difficulty which might potentially impact their editing, it struck me as reasonable to try to offer what assistance I could should any such editors request it when facing a problem related to their difficulties.
 * TheDJ: As a developer I like working on what some people would consider 'fringe' areas. Improve support for uncommon browsers, uncommon languages and also accessibility. Being able to find and discuss with editors that share this interest can be very useful.


 * What are the biggest hurdles preventing users with disabilities from reading and editing Wikipedia articles? How does the project address these issues?
 * Graham87: I'm only familiar with accessibility problems related to screen readers; I have summarized the most important ones at a recent Signpost story.
 * Paul MacDermott: Using a screen magnifier means you see only a portion of the screen at any time, so changes to screen layout can present problems. Also, I personally find some of the Unicode difficult to follow, particularly when adding tables, etc. I have lost count of the number of mistakes I've had to go back and correct. Images can sometimes be an issue too with screen magnifiers (screen freezes, etc), though more recent software seems to be more reliable.
 * John Carter: I believe the project was one of the first advocates for offering specific skins which would be less problematic to people who can't see colors, and a few other similar ideas.
 * TheDJ: People often have a very narrow view of what accessibility means. In practice it means that we strive to make the webpages as accessible to as large a group as possible. That means thinking about a multitude of usergroups who might require a bit of extra work to make reading or editing the pages easier. For instance, this WikiProject has in the past been instrumental in giving feedback on color schemes for both content and interface, taking into account the specials needs of people with colorblindness or similar vision limitations. Screenreader and keyboard navigation is another often-discussed topic. Since Wikipedia still has a rather limited amount of audio and video material, we haven't had to spend as much time on those issues so far.


 * Has WikiProject Accessibility been involved in any of the proposed or implemented changes to Wikipedia's user interface and features, like VisualEditor or Flow?
 * Graham87: The WMF community liaisons have kept us in the loop both individually and as a project about the upcoming changes to Wikipedia's user interface, and I for one have provided some feedback about the notifications system.
 * TheDJ: Unfortunately this still isn't a primary concern of the Foundation, I fear. They have trouble enough getting stuff off the ground without having to consider accessibility as a core concern, unfortunately. However there is a small set of volunteer developers that have done some work on accessibility that are now polled for 'accessibility reviews' of individual changes to the MediaWiki software. Sometimes this leads to questions for feedback to the Accessibility project, which definitely help the software forward. Recently the German Wikimedia Foundation hired Hoo man to specifically solve some of the accessibility issues that had been reported by users and editors in and outside of WikiProject Accessibility.


 * Does the project rely on any outside organizations, standards, or initiatives to determine how Wikipedia's accessibility can be improved? Would it be worthwhile to have an outside observer audit Wikipedia's accessibility?
 * Graham87: We try to adhere to the WCAG 2.0 guidelines where possible. We have received some accessibility feedback from the German Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB)
 * Paul MacDermott: I wonder if an organisation such as the Royal National Institute of Blind People would be worth contacting for advice.
 * TheDJ: A great deal actually. Mostly we rely on W3, and WCAG to set proper standards, for instance. Most importantly in my view, though, is that we are extremely dependent on browser and screenreader vendors. We need these parties to truly invest in these user groups and to collaborate closely with each other to make a healthy ecosystem. From a technical perspective much of the technology required for superb screenreader support is still somewhat stuck in a phase that can be compared with the Internet Explorer 6 era. Standards are inconsistently and, worse, often incorrectly implemented. If the quality and consistency of that part of the web would improve, the Accessibility project and also MediaWiki developers could do a lot more for the users who rely on this technology.


 * Does WikiProject Accessibility collaborate with any other WikiProjects? What initiatives can WikiProjects undertake to improve the accessibility of articles under the project's scope? How can WikiProjects make their own discussion and resource space more accessible for editors with disabilities?
 * Graham87: We don't formerly collaborate with any WikiProjects, but individual members sometimes ask us questions either at the accessibility WikiProject's talk page or the accessibility guideline's talk page. If members of WikiProjects want to become acquainted with the accessibility guidelines, that would be good. To make WikiProject spaces accessible, just use Wikipedia's standard conventions for such things.


 * What are the project's most urgent needs? How can a new contributor help today?
 * Graham87: You can help us by pointing out articles that you think may have accessibility problems, or asking questions about any new techniques or software that might be developed. Also, if you have accessibility issues that we may be able to help with, we'd love to hear about them.
 * TheDJ: I echo Graham here, please share where you are having trouble with your ability to read or edit articles. Solving the 10% most common problems would probably significantly improve the experiences for all readers and editors.


 * Anything else you'd like to add?
 * Graham87: I'd just like to put in a plug for the WCAG theme song. Enjoy!
 * TheDJ: I'd like to add that making content accessible in the basics is not so big a problem. When it comes to Wikipedia, the challenge is often in doing this as 'automatically' as possible, so that ideally it does not require extra effort of editors. The other big challenge is making it more accessible for those who need this extra accessibility, while at the same time not creating too much 'noise' for those who do not desire or require these additional or alternative presentations. These are the most difficult problems to solve. Examples are for instance flatlist and appropriate usage of headings (and not using 'fake' visual headings). This required convincing the editor community of the importance of these simple techniques, even though they might not directly benefit the majority of the editors. Through healthy debate and collaboration with editors these techniques are now commonplace for the past few years, but had not been so for many years in the early days of the project.

Next week's article will be filled with drama. Until then, wash your mouth out with soap in the archive.