Wikipedia talk:WikiProject Accessibility

From Wikipedia, the free encyclopedia
Jump to: navigation, search

You are here: main page >Collaborations >WikiProjects >Accessibility > Main discussion page

WikiProject Accessibility
WikiProject icon This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.

Visual impairment - what settings, software, or other tools are used to compensate[edit]

If you have any degree of vision loss, I'd like to learn what general tools you use, and details of specific setups. Anything from the following list, would be ideal:

  • zoomed-text settings or screen magnification levels (150% 200% etc)?
  • only magnified-text, or magnified-images too?
  • any specific typefaces/fontsizes?
  • whether you copy text into alternate text-editors, or similar workflows?
  • if you use custom style-sheets (eg WP:Style sheets for visually impaired users)?
  • and anything else we ought to know about?

I've found a few threads in the archives here (eg. Vision impairment friendly skin option would help, General Accessibility) but not many mentions of specific settings. I found some related WP:Userboxes/Health#Vision, but I'm not sure where else to find folk. Please nudge anyone that you know, who might be able to help. Thanks! –Quiddity (talk) 06:34, 7 September 2013 (UTC)

Adding Wikipedia:Wikipedia Signpost/2013-09-04/Technology report just to get it on the list. I'll also add that using your browser's zoom function often breaks the formating of pages, but that's probably a different discussion. (talk) 04:40, 10 September 2013 (UTC)
Wikipedia:Using JAWS is probably also worth checking out for anyone who has that. There are a couple of packages I use regularly for everyday tasks, such as word processing, web browsing and editing Wikipedia. I'm sure there'll be many other editors who use these, but I'll give a quick outline of them for anyone who's not familiar with them.
The first is SuperNova, a screen magnifier that enables text to be enlarged to a user's specific requirements, and even allows the text colour and background to be changed. I often reverse the polarity so that I have white text on a black background, which I find can be less straining on the eyes, so an option to do that on Wikipedia would be helpful. I usually set the text size to x5 or x6, depending on what I'm reading. The software will enlarge both text and images, but the downside is that I can only see a portion of the screen, and images can become distorted if they're enhanced too much. Reversing the screen polarity also changes image colour, so any program to do that on Wikipedia would need to address that. Having this software means I can edit Wikipedia, but I tend to have difficulty with anything that involves too much code, such as complex tables.
I have also used Windows magnification, but found problems when wanting to move the pointer to another part of the screen as that remains small and difficult to see regardless of the text size.
The other package I use quite a lot is Kurzweil 1000, a text-to-speech programme that can scan and read documents aloud. This is very useful when reading something lengthy. Kurzweil also provides direct access to articles from Wikipedia, Encyclopedia Britannica and a couple of other online publications. However, although it's possible to retrieve the current version of a Wikipedia article, pages cannot be edited via Kurzweil. In the past I have attempted to copy/paste, then modify documents in their bare format, but that has caused problems when they're transferred back to Wikipedia, since Kurzweil 1000 doesn't recognise some written languages (such as Russian) so will replace the characters with a series of question marks.
Hope this helps, and covers the sort of information you wanted to know. Give me a shout if you have any questions. Paul MacDermott (talk) 16:41, 20 September 2013 (UTC)
Much thanks Paul, that is exactly the kind of thing I was hoping to learn. Feel free to add more details anytime (I've watchlisted this page for years), and I might ask a few more questions later on.
Just FYI, I've had a little bit of experience with Orca on linux, but I need to spend some more time getting to understand how to test it more efficiently. TTFN, –Quiddity (talk) 18:28, 20 September 2013 (UTC)
Glad I could help. Just reading what others are saying below, I'll add a couple of other things. After upgrading to IE8 some time ago I found a glitch that prevented me editing protected articles when SuperNova was running, so had to switch to Chrome, then later found Opera which I prefer because of its drop down menus. Having recently upgraded from Vista to W7, things seem to be ok with the current version of IE (9, I think). Also, I'm still using the old Wikipedia format with the search bar to the left of the page. Changing to this might help anyone whose drop down menus are short of space because of larger text. Paul MacDermott (talk) 12:57, 21 September 2013 (UTC)
Monitor and Zoom - I have a 23-inch widescreen monitor and use both Firefox and Opera. My zoom on Opera is set with Trebuchet MS default font, and zoom is at 120%. Firefox default font is Microsoft Sans Serif. Firefox doesn't give percentage on the zoom, but it's zoomed up as large as it will go and still look like normal type face. Firefox zoomed larger makes everything look like it's on bold face, so I keep it one step below that.
Images - I do zoom images on Commons, but it's a matter of enjoying scrolling around and looking at all the details. If the images are older non-digital, and/or if there is text on the image, zooming is sometimes necessary.
Most annoying problem - Duplications or missing periods, commas, punctuation, coding diffs between bold, italics, etc. It is difficult to see those little things in the edit window, even with a lot of zoom. I catch most on a preview, but often miss them in the Edit window.
WikED - This is a necessity for me in the Edit window. I can do without it, but looking at the Edit window without WikEd is like looking at a big blob of text where nothing stands out to help my editing. And WikEd has some funky quirks that don't get solved, so I work around the quirks.
Colors - It would help if you had an associate on whatever you're working on about this who is over the age of 50 or 60. Colors start to go away, and people begin to have trouble distinguishing between colors in the red spectrum (orange, maroon, pink) . When blues are lightened up (like what has happened recently) on Wikipedia links, to an older person it doesn't even look like links are there. Probably all colors are involved, but those two come to mind.
Definition - People with normal eyesight see the world through crisp, clean digital lens. People with vision problems are often looking through something like a dirty window, images are softer or blurred, or there is a white or yellow film over what they see. It's the difference between Digital and a dirty window.
I hope I've offered you some help. Feel free to ask me other questions you might have. — Maile (talk) 20:44, 20 September 2013 (UTC)
Hello; you asked me to comment on vision problems. My eyesight isn't really bad, but reading small text is tiring, especially if the background is busy or coloured. I use Firefox, and I often zoom in one level (Control+) when editing. I also have Twinkle enabled, the Teahouse options, and then or course there's the new "edit source" tab, and I find that at that zoom level the tabs at the top of the screen won't fit and are shifted down and to the left, obscuring the name of the article. If I am doing something that requires switching from article to article, this means constantly zooming out to use the tabs, and in again to read the text. The obvious fix for this is to have the search box shrink when there isn't enough space for all of the tabs, and grow when there is. Another solution is to put items in the drop-down under the little triangle as Twinkle does when there isn't enough space. In fact, it seems to me that the interface used to do this, but of course I now can't remember under what circumstances. —Anne Delong (talk) 20:15, 20 September 2013 (UTC)
Maile and Anne, that is great feedback, with both specific details, and specific problems. Much thanks to you both. I'll try to mention or pass along all these points, to as my locations as I can think of. TTFN, –Quiddity (talk) 21:57, 20 September 2013 (UTC)

Discussion about collapsing music track lists[edit]

Dear All: There is a discussion about whether the track lists for Music of the SaGa series should be collapsed in the article at Talk:Music_of_the_SaGa_series#Collapsed_sections. Please visit the talk page and take a few moments to share your feedback on this issue. --Jax 0677 (talk) 01:33, 19 September 2013 (UTC)

Category:Articles overusing colours[edit]

Category:Articles overusing colours, which is the tracking category for the templates {{overcolored}} and {{overcoloured}}, is under discussion at Wikipedia:Categories for discussion/Log/2013 September 21#Category:Articles overusing colours. --Redrose64 (talk) 14:39, 21 September 2013 (UTC)

WP Accessibility in the Signpost[edit]

The WikiProject Report would like to focus on WikiProject Accessibility for a Signpost article. This is an excellent opportunity to draw attention to your efforts and attract new members to the project. Would you be willing to participate in an interview? If so, here are the questions for the interview. Just add your response below each question and feel free to skip any questions that you don't feel comfortable answering. Multiple editors will have an opportunity to respond to the interview questions, so be sure to sign your answers. If you know anyone else who would like to participate in the interview, please share this with them. Have a great day. –Mabeenot (talk) 02:08, 18 October 2013 (UTC)

Line breaks[edit]

My eyesight and coordination are not great. I sometimes find it hard to position the cursor precisely using the mouse. I swap text around a lot when I start an article until I am satisfied with the sequence. I prefer to start new sentences on new lines. If the sentence is on a line or lines by itself I find it easier to select the sentence, then cut it and paste it somewhere else. I click at the end of the line, pull back to the start of the sentence, then CTRL+X, CTRL+V to move it. It is harder for me to select and move text that is embedded in a line or lines. Sometimes editors take the line breaks out. Is there a reason for this? Aymatth2 (talk) 03:09, 5 November 2013 (UTC)

See the fairly old essay Wikipedia:Don't use line breaks. I myself don't like them as a screen reader user because they make it harder to arrow through the wiki-markup. Graham87 06:16, 5 November 2013 (UTC)
That is awkward. Line breaks at the end of each sentence make it a bit easier for me to edit, but harder for you. Is it a lot harder, or just a bit harder? The essay is inconclusive and does not mention mouse coordination or screen reader issues. While an article is being created presumably the author's choice should be respected. After that, I don't know. I suppose I mostly care about keeping end of sentence line breaks while I am working on the article. Aymatth2 (talk) 14:49, 5 November 2013 (UTC)
Only a bit harder. Having them at the ends of sentences (thus in a predictable location) wouldn't be as bad as me as having them every fifty characters or so, as one editor did a very long time ago, inspiring me to write about it it in my first major post about accessibility. That admonition is still in the accessibility guideline, but I'm not that attached to it; it'd probably best to ask about it at the guideline's talk page as well. Graham87 04:03, 6 November 2013 (UTC)
Have you considered creating articles in your userspace, and not moving them to mainspace until you're mostly done editing them? No one is likely to mess with them overmuch while they're in userspace. Maralia (talk) 04:12, 6 November 2013 (UTC)
I would find that awkward. Once I have a fair start to a new article, I search for related articles and link them to the new one, then use "what links here" as a checklist for other aspects that should be covered. Once I have "finished" an article, it often has redlinks I want to turn blue. That process, starting new related articles, often turns up content that belongs in the earlier article - sometimes quite a lot. It is never clear when the article will be mostly done. "After it has been unchanged in mainspace for a month or so" maybe. I will raise the question on the accessibility guideline talk page. Aymatth2 (talk) 13:59, 6 November 2013 (UTC)

Hlist heads up[edit]

Problems reported at Wikipedia:Village_pump (technical)#Pages_inaccessible_using_IE8 have resulted in changes to the {{hlist}} template. I know some of you are interested in things like this, so there's a pointer if you want it. WhatamIdoing (talk) 22:50, 17 November 2013 (UTC)

The template hasn't changed, and nor has the underlying module. What has changed is MediaWiki:Common.css, where the white-space: nowrap; declaration has been removed from all rules which include the hlist class in the selector. --Redrose64 (talk) 11:21, 18 November 2013 (UTC)

wp miss (and more) nominated for deletion[edit]

wp miss and other redirects have been nominated for possible deletion. If you would like to participate in the discussion, you are invited to add your comments at the redirect's entry on the Misc. for discussion page. Thank you. XOttawahitech (talk) 16:16, 6 December 2013 (UTC)

Composition bar[edit]

Accessibility issues with {{Composition bar}} are being discussed at Template talk:Composition bar#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 17 December 2013 (UTC)

Verison template[edit]

There are serious accessibility issues with {{version}} (and tables in articles using it as a legend), which relies on the background colours of table cells to provide information. Please discuss at Template talk:Version#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:21, 23 December 2013 (UTC)

Template:Start date[edit]

There is a discussion at Template talk:Start date#Minus sign in time zones which might interest this WikiProject; it concerns other matters besides the minus sign. --Redrose64 (talk) 23:24, 26 December 2013 (UTC)

RFC: spacing of mixed fractions[edit]

An RFC has been started at Wikipedia talk:Manual of Style/Dates and numbers#Spacing of mixed numbers in relation to the spacing between the whole number and the fraction in mixed fractions (e.g., 1 23). As this involves accessibility issues on the presentation of such numbers (for example, screen readers may have difficulty parsing the number correctly without a space), I have posted this here to invite further comments from interested Wikipedians. sroc 💬 05:50, 28 December 2013 (UTC)

Complex infographics[edit]

Complex infographics giving a large number of facts, like File:Human Aquatic Adaptations.png, used in Aquatic ape hypothesis; and File:Human Running Adaptations.png in Endurance running hypothesis, are being discussed at:

Your comments would be welcomed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 31 December 2013 (UTC)

Page length[edit]

2013 in film is 332,397 bytes (without images). Please discuss whether or not to sub-divide it, at Talk:2013 in film#Length. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 16 January 2014 (UTC)

RFC on left-aligned images[edit]

Hi. Please be aware that a discussion is going on at WT:Manual of Style/Images#Request for comment, asking whether the portion of the guideline advising against placing left-aligned images directly below level-3 subheadings ought to be removed. The consensus so far is overwhelmingly in favour of removing this recommendation, though some objections have been raised on accessibility grounds. People here who have insights on the accessibility ramifications of this proposed change might wish to go comment on the RFC. — Richwales (no relation to Jimbo) 18:05, 26 January 2014 (UTC)

Opendyslexic font?[edit]


I suggested a few months ago to a dyslexic friend of mine (a Web accessibility expert, well known in France and Belgium) to have a look at the "opendyslexic functionality" that had been implemented. I suspect it was removed with the "universal language selector" (sorry, I can't remember the proper name).

She was a bit disappointed because the font did not correct her main concerns. She suggested to shorten the lines, to increase the line heights and spaces between the paragraphs. She was also complaining that the default font size required a zoom of 130% to become readable for her.

Where could I forward those informations to the devs?

Thank you! GChagnon (talk) 22:53, 10 February 2014 (UTC)

You could use the email address listed on the OpenDyslexic website, in case you haven't already done so. Graham87 02:01, 11 February 2014 (UTC)

DYK Nominations[edit]

I've raised a concern with the accessibility of the formatting used for "Did You Know" nominations; please see Wikipedia talk:Did you know#Formatting and bullets. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 15 February 2014 (UTC)

Watchlist's "green bullet" (page updated since last visit) feature inaccessible[edit]

a report has been loggged in the Village Pump's technical section which details the technical (and resultant end-user) problems posed by the use of purely visual indicators to denote the status of items which appear in document divisions marked class=mw-changeslist in the rendered document source for the Wikipedia Watchlist... the report was sparked by the following prose, which appears in the second paragraph of the introductory text for the Watchlist, immediately preceding the "Mark all pages as visited" button in the document's reading-order:

Pages that have been changed since you last visited them are shown with a green bullet.

the report details why this "feature" is inaccessible to the blind, as well as those with color vision deficiencies -- in particular: monochromacy, achromatopsia, red-green color-blindness, tritanopia and tritanomaly... it also specifies violations -- inherent in the feature's design and implementation -- of the W3C's Web Content Accessibility Guidelines and Wikipedia's own Manual of Style... this "feature" should never have been implemented on Wikipedia, and the clear and obvious problems identified in the report at the Village Pump should have been detected and corrected by those who construct and vet the templates for Wikipedia -- their failure to do so is inexcusable.... therefore, means of immediately rectifying the problem -- and preventing a recurrance of the mplementation such a "feature" in the future -- have been provided via the Village Pump technical report...

the "feature", as defined by the style rules contained in code conatined in divs marked class="mw-changeslist", cannot be made accessible with any existing (or emerging) technology, because images inserted using list-style-image are cannot currently be programmatically associated with textual equivalents, such as the use of the native HTML attribute alt or by use of ARIA's aria-label or aria-labelledby, and therefore needs to be re-engineered and replaced, either through the scripted, rather than a CSS-generated, insertion of an image into the document source to indicate that the listed item has changed since the user's last visit using the IMG/alt tandem oedipus (talk) 05:58, 16 February 2014 (UTC)

WP:TOC and ignoring accessibility[edit]

People are ignoring "If floating the TOC, it should be placed at the end of the lead section of the text, before the first section heading. Users of screen readers do not expect any text between the TOC and the first heading, and having no text above the TOC is confusing. See the last line in the information about elements of the lead section." They state this can be ignored for any reason and no consensus was ever had on this matter. A call for a RFC is at User talk:Bgwhite#TOCs. Bgwhite (talk) 23:23, 19 February 2014 (UTC)

Recent font change - type face[edit]

See Wikipedia:Village pump (technical)#Font size and style for more info.

To change back to the old style (sans-serif style in Vector).....

Go to Preferences → Gadgets → Vector classic typography (use only sans-serif in Vector skin)
-- Moxy (talk) 02:04, 4 April 2014 (UTC)
Moxy, the main reason for changing fonts was for accessibility. The font size and line height have been increased. Those with vision problems, like me, no longer have to increase the browser's font size. Also, the new style is what the end reader will see. If you are doing tables, images or other things to certain sizes or placements, the end reader will see something different than what you see. I keep running into that problem with editors. Bgwhite (talk) 04:42, 4 April 2014 (UTC)
As has been mentioned at the link above by many, readability has diminished because of the font style. Thus the reason for this notification. I aslo have vision problems and the style is a problem for me - size is good though. -- Moxy (talk) 05:05, 4 April 2014 (UTC)

RfC on use of plainlist[edit]

There is an RfC on whether to use the {{Plainlist}} template for lists in the infobox at Talk:Michaëlle Jean #RfC: Should the lists in the infobox use the Plainlist template?. As this is essentially a question of accessibility, I am placing a notification here as the relevant WikiProject. --RexxS (talk) 22:28, 15 April 2014 (UTC)

User warning for inaccessible sigs[edit]

I have created a level one warning template, {{Uw-sigdesign1}}, which reads:

Information icon Hello, I'm [Username]. I wanted to let you know that your signature ("sig") design might cause problems for some readers. This is because of low colour contrast, an unreadable font, or suchlike. If you think I made a mistake, or if you have any questions, you can leave me a message on my talk page, or take a look at our guidelines and policy on customising sigs. Thank you.

where "of low colour contrast, an unreadable font, or suchlike" can be replaced by |1= and "Thank you" by |2=.

I invite comment about its content and deployment, including the possibility of using it in twinkle, on its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 18 April 2014 (UTC)


The accessibility of abbreviations of "circa" is being discussed here. Your thoughts would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 19 April 2014 (UTC)

Background colours on templates[edit]

Wikipedia:Manual of Style/Accessibility#Color (WP:COLOR) states:

Some readers of Wikipedia are partially or fully color blind. Ensure the contrast of the text with its background reaches at least WCAG 2.0's AA level, and AAA level when feasible.

This is very sensible advice.

Some templates use background colours, e.g., to highlight discussions that have closed. For example, {{cfd top}} uses #bff9fc, {{sfp top}} uses #99ff99, {{sfp nocreate}} uses #ff9999, and so on (I am indebted to David Levy for researching these). This is not an issue when writing in black text, provided that these provide a contrast ratio of at least 4.50:1 as is required for "AA" level compliance. However, this can become an issue when using text in other colours, such as links (#002bb8) and formatting applied by templates such as {{xt}} (#006400) and {{!xt}} (#8B0000) where the contrast ratio falls below this level.

This has become an issue in a discussion at Template talk:Tq#RfC: Change the TQ template font colour where is it proposed to change the colour of the {{tq}} template (currently #008000) because of its similarity to the {{xt}} template, but it is difficult resolving on a specific colour because they all clash with background colours used on various templates.

I would suggest that templates should avoid using such background colours, except in a very light range, as this substantially restricts the ability to use font colours without breaking accessibility. For example, the {{sfp top}} template could use the bright green in the background of the header (where the predefined text is all black and red) and use the same colour for borders around the closed discussion, but leave the background behind the discussion as transparent (or a very light shade that would not interfere with any text colours) in order to preserve accessibility regardless of what font styles are used in the discussion.

Should this be introduced as a policy or guideline for all templates? sroc 💬 06:47, 21 April 2014 (UTC)