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.

Content color blindness accessibility[edit]

I'm drafting a grant application for a color blindness detector at meta:Grants:IEG/Color blindness content checker. Only a 6 month process for 2 weeks worth of work. — Dispenser 17:22, 4 May 2015 (UTC)

On a related note there's a TTS proposal. I find it a silly idea. — Dispenser 17:47, 4 May 2015 (UTC)
I forgot to mention it here, but you might be able to still sneak a support under the wire at m:Grants:IEG/Alt text tools. — Dispenser 12:27, 30 September 2015 (UTC)

Mobile changes[edit]

Hi everyone, there are some proposed design changes for how the lead section of the article could be displayed on mobile web. The rationale and specifics of the change are elaborated on the mediawiki page. Please take a look and post your suggestions to the talk page. Whatamidoing (WMF) (talk) 17:24, 18 August 2015 (UTC)

Editors adamant on flouting WP:COLOUR[edit]

Another day on Wikipedia, another war of attrition on the topic of accessibility. Enjoy. Alakzi (talk) 07:39, 26 August 2015 (UTC)

Line color cat[edit]

@AlexTheWhovian, Alakzi, and Favre1fan93: Found a glitch in Category:Episode lists with invalid line colors. It appears that LineColor=none causes the page to be categorized as an invalid line color. For example, see The Adventures of Don Quick. EvergreenFir (talk) Please {{re}} 20:25, 27 August 2015 (UTC)

@EvergreenFir:, that is an invalid color, but can be fixed by simply removing the parameter. it could be useful to ignore the cases where there is no shortsummary. although, just fixing the articles works as well. Frietjes (talk) 20:30, 27 August 2015 (UTC)
Okay... it's not a WP:COLOR violation, but I guess that makes sense to include them. EvergreenFir (talk) Please {{re}} 20:34, 27 August 2015 (UTC)
I don't think ignoring cases where there is no short summary would be helpful, because if a summary ever is added, the line color will appear and will be invalid. - Favre1fan93 (talk) 21:51, 27 August 2015 (UTC)

Episode lists with alternating color rows[edit]

Suggest that when we encounter pages with episode lists that have alternating row background colors (e.g., List of Fifth Gear episodes and List of Top Gear Australia episodes), we convert them to templates (e.g., List_of_The_Simpsons_episodes#Episodes. The latter seems to be the most common way of listing episodes and now that Category:Articles using Template:Infobox television season with invalid colour combination is cleared out we can be sure the color combos are adhere to WP:COLOR.

On a related note... I'd love to see the series overview sections converted to a template so that they can be tracked with the categories. Most seem to use plain wiki table code. Is this something we could get a bot to handle perhaps, or a script? EvergreenFir (talk) Please {{re}} 20:42, 27 August 2015 (UTC)

A template exists, once again courtesy of Alex {{Series overview}}. - Favre1fan93 (talk) 21:50, 27 August 2015 (UTC)
And those two examples you linked should definitely use the standard ep table format, without the color alternating rows. - Favre1fan93 (talk) 21:52, 27 August 2015 (UTC)
Thanks. I'll change them when I see them. EvergreenFir (talk) Please {{re}} 21:56, 27 August 2015 (UTC)

More colour tracking categories[edit]

There's no end in sight, is there? Alakzi (talk) 19:08, 28 August 2015 (UTC)

If there were a end in sight, somebody would edit the background to make sure we couldn't see it. --RexxS (talk) 00:09, 29 August 2015 (UTC)
You've got to wonder, just what were they thinking? Alakzi (talk) 00:21, 29 August 2015 (UTC)
But colors! ~ RobTalk 00:23, 29 August 2015 (UTC)
After having laid my poor eyes on Great North Run (that's Great North Run), I've decided to improvise. Alakzi (talk) 00:26, 29 August 2015 (UTC)
Rather than going such an extreme route, which will almost certainly be reverted and probably should be, have we considered maybe gaining wide consensus on how WP:COLOR violations in infoboxes should be dealt with? I bet it would be very easy to get consensus at an RfC to template the talk pages of violations and then change the template to disallow invalid color combinations 14 days later after editors have a chance to address the issue. Standardizing the procedure on how to do this would avoid having to seek consensus on how to implement this dozens or hundreds of times as we uncover more and more templates with frequent violations. ~ RobTalk 01:09, 29 August 2015 (UTC)
Consider discussing this at WP:VILLAGEPUMP, where individual WikiProjects won't feel as threatened or be as likely to defensively protect their territory.—Bagumba (talk) 01:22, 29 August 2015 (UTC)
I could handle an AWB bot to template those talk pages, by the way. ~ RobTalk 01:11, 29 August 2015 (UTC)of
Maybe consider excluding those which have no text on the background colour. They simply have a short bar of colour. All the best: Rich Farmbrough, 01:44, 29 August 2015 (UTC).
WikiProject Accessibility
Date First Sunday following 5 January
WikiProject Accessibility
Date First Sunday following 5 January
That was just Alakzi's improvisation I guess.
How about this? (Using the tools you guys have already made to automatically chose black or white text.)
All the best: Rich Farmbrough, 02:19, 29 August 2015 (UTC).
That's what we usually do, but we're still going to have to fix the AA's. Alakzi (talk) 08:06, 29 August 2015 (UTC)
First category clear. Alakzi (talk) 08:49, 29 August 2015 (UTC)
BTW 4.5 is fine for 18pt or 14pt bold. I created the poorly named {{Ensure AA contrast ratio}} for this reason. Guess I should move it to {{Ensure 4.5 contrast ratio}}. All the best: Rich Farmbrough, 14:36, 29 August 2015 (UTC).
The specification defines 14 pt as "roughly equivalent to 1.2 ... or to 120% ... of the default size for body text (assuming that the body font is 100%)". The headers are 15.4 pixels in size, where the default is 16 pixels, and thus roughly 96% of the "default size for body text". Alakzi (talk) 14:43, 29 August 2015 (UTC)
IS that a vector thing? Because for me, in Monobook, the headers are twice the body text. All the best: Rich Farmbrough, 17:48, 29 August 2015 (UTC).
Nominally 15.8833px vs 12.7px = 1.2506535433071. All the best: Rich Farmbrough, 17:55, 29 August 2015 (UTC).

(BTW [1] this editor seems to have made some of the odd changes of colour.) All the best: Rich Farmbrough, 00:31, 30 August 2015 (UTC).

AWB now removes blank lines between a list[edit]

Just added to the development version, AWB will now remove blank lines between unordered lists per WP:LISTGAP. This will be available in the next stable release of AWB. Bgwhite (talk) 17:03, 4 September 2015 (UTC)

Cool! How about lists separated by image markup? Graham87 06:26, 5 September 2015 (UTC)
Magioladitis has added it to his todo list. It will be added as an alert instead of AWB moving the images. Moving image could get tricky. Bgwhite (talk) 07:33, 6 September 2015 (UTC)

Color palette of Wikimedia projects to comply with WCAG 2.0 AA[edit]


I'm in contact with M Galloway (WMF), alias violetto. She is working on the following task :

This project could be really useful for accessibility. I've noticed a few other projects from her that aims to improve accessibility, she seems to be doing a good job. She contacted me asking for my opinion, I've offered a collaboration. And I recommeded user:RexxS to her, he might be more active than me ?

I'm just keeping you updated on what is currently happening. Not much you can do to help at this point. Cheers, Dodoïste (talk) 14:35, 16 September 2015 (UTC)

Please see a discussion[edit]

You are invited to comment at Wikipedia talk:Manual of Style/Accessibility#Colour. BethNaught (talk) 16:00, 20 September 2015 (UTC)

Baseball template colors discussion[edit]

The discussion at Wikipedia_talk:WikiProject_Baseball#Proposed_color_changes may be of interest to members of this WikiProject, as it's delving into contrast issues. ~ RobTalk 01:13, 24 September 2015 (UTC)

Accessibility of the... Wikiproject menu ![edit]

Hi there,

When the Wikipedia:WikiProject Accessibility/Navigation menu was standardised trough the Sidebar template, some of its qualities were lost in the process.

Notably, color contrast. The foreground color #0144AC of the [show] / [hide] links in the blue background #DDDDFF was AA compliant but not AAA. And the layout was terrible.

So I've improved this menu a little. I believe the WikiProject itself should be a good example of its own guidelines. :-) Cheers, Dodoïste (talk) 22:04, 29 September 2015 (UTC)

Frequently asked questions and misconceptions[edit]


I've been wanting to write this page for several years : Wikipedia:WikiProject Accessibility/FAQ and common pitfalls. I've just started with one example.

Do you have any ideas of FAQ or common misconceptions to share ? My imagination is lacking. :-) Dodoïste (talk) 22:29, 29 September 2015 (UTC)

Yes; it's a misconception that AA is "good enough". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:21, 30 September 2015 (UTC)
What Andy said, basically. Policy requires us to meet AAA "wherever feasible". Since color is never essential to navigating the site (except in actual images, where we need an accurate representation of reality), it is always feasible to meet AAA in things like templates, and therefore required by policy. ~ RobTalk 00:40, 30 September 2015 (UTC)
Thank you, Rob. I've reused your wording in the above document, Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 30 September 2015 (UTC)
Your answers are really interesting. I think I was right to bring this topic to discussion. As it turns out, some things have evolved since 2010 and I needed an update too.
I think we can all agree that the most important requirements are A level requirements because they are the most critical and they have the most impact. Meeting only A level requirements is "not enough". We should at least achieve AA level. I guess saying that AA level is "good enough" was a really bad way to put it. Some AAA level are easy to achieve and have some impact. But at the same time, aiming for AAA level without prioritization or distinction between the criterias is a really bad idea.
What do you people think about the current level of accessibility on Wikipedia ? Do you think we meet all A level requirements ? Should we not ensure that we already meet A level requirements before aiming for AAA level ?
It also raises the question of the benefit of meeting AAA level requirements. If I recall correctly, some AAA level guidelines are not adequate for all websites. Each website has to weight the cost / benefit to meet AAA level requirements.
I believe Wikipedia should aim for AA level consistently, plus all Level AAA guidelines we can reasonably meet. But not all AAA guidelines.
Here are some sources :
Dodoïste (talk) 13:31, 30 September 2015 (UTC)
"Should we not ensure that we already meet A level requirements before aiming for AAA level ?" No; if page X fails "A", but fixing it will be difficult (either technically or, say, because of a lack of consensus as to how to proceed) and page Z fails "AAA", but can easily be fixed, page X is not a reason not to fix page Z. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:02, 2 October 2015 (UTC)
Sure. :-) I feel like I'm really having a hard time to express my thoughts clearly. I'll try differently.
My point is that I have the feeling that several people might insist a lot about reaching AAA level - even when it's a difficult case. For example, reaching AAA color contrast is often really difficult for several WikiProjects that use a particular color scheme. But some people might insist that AA level is not good enough, we have to be perfectly accessible. Thus spending a lot of energy on a particular case, without looking at the big picture. There might be more crucial accessibility problems to fix. And aiming to reach AA accessibility level is already a very difficult challenge given the nature of Wikipedia. Dodoïste (talk) 00:16, 3 October 2015 (UTC)

Bolded Japanese characters[edit]

Bolded Japanese characters appear to be quite hard to read for those with 20/20 vision, let alone those who have impaired vision. As many templates that may include Japanese characters apply bold font weights automatically, this could affect a large number of articles without editors even intending to use the bolded text. I've started a discussion on how we might go about fixing this at Wikipedia_talk:WikiProject_Japan. I encourage you to take a look at the discussion and participate. ~ RobTalk 01:39, 30 September 2015 (UTC)

These bolded characters might indeed be difficult to read. And I think you are right. I just want to inform you that this has nothing to do about accessibility. It's about readability. Dodoïste (talk) 13:34, 30 September 2015 (UTC)
Why do you think that readability is not part of accessibility? --RexxS (talk) 12:48, 1 October 2015 (UTC)
Because it impacts all users regardless of disability. There is no discrimination.
For example, imagine that someone would seal the entrance of a building with a wall of bricks. Sure, disabled people would not have access to it, but noone would. There is no discrimination in that. Dodoïste (talk) 23:01, 1 October 2015 (UTC)
But that would still reduce the accessibility of the building, wouldn't it? Let me make this clear: The International Organization for Standardization defines accessibility as the "extent to which products, systems, services, environments and facilities can be used by people from a population with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use." (ISO TC 159). It is a mistake to think that accessibility only applies to people with disabilities, and we have a duty to ensure that the content of our website "can be used by people from a population with the widest range of characteristics and capabilities". Readability is very much an integral part of of accessibility and is clearly in the scope of this WikiProject. --RexxS (talk) 19:42, 2 October 2015 (UTC)
There are several definitions for "Accessibility". One refers to most of the "normal" population being able to access the building - omitting people with disabilities. One refers to people with certain disabilities being able to use the building - omitting "normal people". The definition you wrote would rather refer to universal accessibility.
I'm not opposed to broaden the scope of this WikiProject. But so far we have followed W3C's Web Accessibility Initiative approach and guidelines. Their definition of accessibility is only about people with disabilities... All of our guidelines are about the disabled. We haven't written anything regarding "accessibility for normal people" or universal accessibility so far in this project. Dodoïste (talk) 23:50, 2 October 2015 (UTC)
The following guidelines in WP:ACCESS wholly or partly contain guidance aimed at improving accessibility for readers and editors not normally considered as having a disability:
so I'd say that the scope of the project is broadened already. WAI does indeed have a mission to improve accessibility for people with disabilities, but that doesn't mean it has to monopolise our concerns for accessibility. WAI says nothing about making our websites fully available to people in developing countries who are not disabled, but may have old technology, low bandwidth, small screens, or a combination of those. Nevertheless, they still need our attention to their needs. Similarly, being old is not considered a disability by WAI, but older viewers still need to be able to read our content, which, for example, effectively sets a lower limit on the size of text that we can use. It is fortunate that the changes to increase accessibility for people with disabilities will usually increase accessibility for others as well - as WCAG notes on its opening page. I'm not advocating any special treatment for those other groups, but I do firmly believe that if we don't concern ourselves with readability issues here, we can be pretty certain they won't be addressed anywhere else. --RexxS (talk) 01:37, 3 October 2015 (UTC)
Fair enough. :-)
These parts, especially the one about screen resolution have always disturbed me. They are important but they are not based on a source or anything. Which makes it difficult for us to handle as volunteers. I believe these are topics that the Wikimedia Foundations team of designers would need to address one day and make an official statement about what they recommend.
Until that happen, okay, fine with me. :-) Dodoïste (talk) 23:36, 5 October 2015 (UTC)

Web Accessibility - topic for November 10 Tip-Of-The-Day[edit]

Greetings! On November 10, the Tip-Of-The-Day is about the web accessibility. The tip is Editing articles for web accessibility and includes a link to Wikipedia's web accessibility page.

This November 10 tip was recently added at the TOTD Schedule Queue and is also posted at the Tips library. Regards, JoeHebda (talk) 23:30, 30 September 2015 (UTC)

Thanks a lot ! I replied at the talk page Wikipedia talk:Tip of the day/November 10. Dodoïste (talk) 00:04, 3 October 2015 (UTC)

Adjectival format and Google Search speech-to-text[edit]

A report here refers to Panama Canal which starts with the following (simplified):

The Panama Canal is a {{convert|77.1|km|mi|0|adj=on}} ship canal
The Panama Canal is a 77.1-kilometre (48 mi) ship canal

The report says that Google's text-to-speech (after a search) says "seven seven point one dash k-i-l-o-m-e-t-r-e". Is there anything wikitext can do to workaround that issue? Johnuniq (talk) 22:43, 9 October 2015 (UTC)

As it said in the original discussion, that's Google's problem, not ours ... and the only way I could think to solve it would degrade the experience for mainstream users (replacing the hyphen with a space). Google's screen-reading products (especially those related to browsers) aren't widely used by blind people. Graham87 10:35, 10 October 2015 (UTC)
Thanks Graham, that makes sense. Johnuniq (talk) 01:58, 11 October 2015 (UTC)

Broken subtitles[edit]

Hey All. I've just discovered that a lot of subtitles for audio and video files don't work properly. You can see (what I think is) the full list here if you want to help. You can fix them by putting them into SubRip text file format. Thanks. Brustopher (talk) 15:32, 30 October 2015 (UTC)

For users interested in this, I recently wrote a Quora answer that details how to write Wikipedia subtitles using —TheDJ (talkcontribs) 11:10, 27 November 2015 (UTC)

Accessibility of new notification icons[edit]

I have raised concerns about the accessibility to those with poor eyesight of the new, paler, notification icons (mentions, talk page messages, etc) at Wikipedia talk:Notifications#Notification icon colours. It would be appreciated if knowledgeable people could comment there. Thryduulf (talk) 02:40, 20 November 2015 (UTC)

Discuss: 'Back to contents' template[edit]

Greetings, Recently I added the {{Back to contents}} template to Wikipedia talk:Tip of the day at each of the 12 monthly Tip maintenance sections. Then at Template:Back to contents I noticed this template is being discussed for deletion at Wikipedia:Templates for discussion/Log/2016 January 13#Template:Back to contents. Wondering if keeping the template would be useful for accessibility purposes? Please send your responses to the above deletion discussion link. Regards,  JoeHebda (talk)  15:48, 18 January 2016 (UTC)

Content donation of Audio Descriptions[edit]

Hi, VocalEyes has recently donated 40 audio recordings of audio descriptions of London landmarks, scripted for blind and partially sighted people. You can find them here on Commons Matthewcock (talk) 16:50, 18 January 2016 (UTC)

Help with alt text for Infobox oganization template[edit]

{{Infobox organization}} lists in the /doc a parameter for logo_alt but when editing a page with this included the server complains: "unknown parameter 'logo_alt'. If someone experienced with editing these things (I don't want to break it) could include the logo_alt feature so visually impaired individuals have access to same visual information that would be very helpful. -- dsprc [talk] 21:05, 25 January 2016 (UTC)

I see no reason that the template should be complaining. The text includes
| image2 = {{#invoke:InfoboxImage|InfoboxImage |image={{{logo|{{{organization_logo|{{{Non-profit_logo|}}}}}}}}} |size={{{logo_size|}}} |sizedefault=250px |alt={{{logo_alt|}}} }}
which clearly indicates it should be usable. Might be something wrong with Module:InfoboxImage. --Izno (talk) 22:04, 25 January 2016 (UTC)
It has been fixed.[2]; was simply left out of supported params. -- dsprc [talk] 22:12, 25 January 2016 (UTC)

Extended WAI-ARIA attribute support[edit]

The MediaWiki version to be deployed next week (1.27.0-wmf.12) whitelists the following attributes for all HTML elements:

  • aria-describedby
  • aria-flowto
  • aria-label
  • aria-labelledby
  • aria-owns
  • role (all values, not just presentation)

Now's a good time to brainstorm. I can think of a few possible uses for this. role="note" at Module:Hatnote, for example. Any other ways these attributes can help? Matt Fitzpatrick (talk) 22:32, 28 January 2016 (UTC)


This section is a followup to a message at Wikipedia talk:Manual of Style/Accessibility.

See the bot request for approval at Wikipedia:Bots/Requests for approval/BG19bot 9 for the discussion to approve a bot to remove blank lines between list items, per WP:LISTGAP. – Wbm1058 (talk) 13:25, 5 February 2016 (UTC)


* a

* b

* c

<li>a </li>
<li>b </li>
<li>c </li>

Spoken by a screen reader as "List of 1 items, a, list end; List of 1 items, B, list end; List of 1 items, c, list end"

* a
* b
* c

<li>a </li>
<li>b </li>
<li>c </li>

Spoken by a screen reader as "List of 3 items, A, B, C, list end"

A list separated by single blank lines appears as a single list to visual readers, but not to audio readers[edit]

  • a
  • b
  • c

To make separate lists, use two blank lines to start a new list (but the two blank lines will only look like one oversized blank line)[edit]

  • a1
  • a2

  • b1
  • b2

  • c

Spacing between items[edit]

Use the "HTML comment trick" to add a blank line between items in the wikicode to avoid editor confusion. This is done with a commented-out line:

* First item<!--
* Second item

This doesn't produce unwanted visible spacing or bad list code in the rendered page like adding a plain blank line would:

  • First item
  • Second item