Wikipedia talk:Manual of Style/Accessibility

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style
WikiProject icon This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.
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.
the Wikipedia Help Project (Rated B-class, Mid-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article B  This page does not require a rating on the project's quality scale.
 Mid  This page has been rated as Mid-importance on the project's importance scale.

Windows-1252 symbols[edit]

Wouldn't Windows-1252 symbols be unpronouncable to Mac or Unix screen readers? Would it be better to restrict non-imaged/non-templatized symbols to Latin-1? Thisisnotatest (talk) 21:43, 26 September 2015 (UTC)

Most symbols are skipped by a lot of screen readers. JAWS won't even read †, which is why we have {{dagger}}. I'd recommend restricting symbols to those that you can type directly from a keyboard. --RexxS (talk) 22:01, 26 September 2015 (UTC)
@RexxS: Thank you for the quick response. On Mac OS X that would include excluding characters that can be reached via option-key or option-shift-key.
Rather than explaining which characters can be used, I suggest just listing the okay characters (using the characters themselves) that don't need to be imaged. Then nobody has to figure it out. And screen-reader users can easily point out erroneous inclusions because they'll hear them. (And why does # (shift-3) have a template {{Hash-tag}}?)
I think it's good to say most symbols will be read as question marks by nearly all screen readers, but we need to not go into the technology (Latin-1, Windows-1252) on an MOS page and stick to what they are to do or not do, so it's unambiguous. Maybe a Details link for people who want more information. Or am I missing something?
Thisisnotatest (talk) 22:41, 26 September 2015 (UTC)
1. Some screen readers will just ignore some unknown characters, rather that speaking "question mark", so we really ought not to put the burden on screen-reader users to spot erroneous inclusions for us.
2. I agree that a list of good choices is sensible. That's [A-Z], [a-z], [0-9], [!£$%^&*()-=_+/@~#<>?\|{}] - have I missed any? A lot of the time, we use symbols in lists to mark a footnote; for those the choice is best kept to # * + $ and maybe one or two others.
3. The {{Hash-tag}} was created by a very keen editor in imitation of {{dagger}}, and I didn't have the heart to tell him that screen readers could cope with '#'. A secondary reason is that the image-symbols take alt text, and this may be better for screen-readers than having to wait till the end of the list/table to get the explanation for the symbol. A list of the players in a cricket team, for example, is nicer if we use {{†|alt=wicket keeper}} to mark the wicket keeper. It's sometimes good to use {{Hash-tag}} in a similar way. Cheers --RexxS (talk) 23:07, 26 September 2015 (UTC)
@RexxS: Thank you. Then I suggest replacing:

Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read.

  1. Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
  2. Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
  3. Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template dagger (see Category:Single-image insertion templates for more).


Many screen readers will read most special characters as a question mark or not at all.

  1. Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
  2. Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
  3. Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template dagger (see Category:Single-image insertion templates for more).
  4. Safe symbols to use without a template are any of the following: !£$%^&*()-=_+/@~#<>?\|{} as well as A through Z, a through z, and 0 through 9.

Thisisnotatest (talk) 01:22, 27 September 2015 (UTC)

This sounds reasonable, I guess, but characters like the dagger are alright in isolation, just sometimes not when they're attached to text. Ditto with "–" and other characters. Graham87 07:31, 27 September 2015 (UTC)
My opinion is actually that that is totally unworkable and unacceptable. Use the proper characters where they are useful and appropriate. Don't do crazy workarounds for them 'just' for screenreader purposes. That is more likely to encourage browser/OS/screenreader vendors to catch up then anything else. The reason I say this, is that basically the above translates to: "screen reader accessibility requires a reduce symbol set". Which is dumb, because the world is about a lot more scripts than just latin script. By plugging these holes, we are doing the rest of the world/web a disservice, by pretending the world is 'prettier' then it actually is. Screenreaders should support all scripts (ideally) but definitely all symbols. They don't even have to do much work for that, the entire unicode table has simple accessible descriptions for every single symbol already. It's laziness and unwillingness of vendors that makes these parts of the web inaccessible, not us. I fully support the desire to make the web accessible for anyone, but I'm totally opposed to this kind workarounds. History has proven that it doesn't work for more than just the paltry 0.1% that editors (web and wiki alike) will get around to fixing after everything has been authored already. —TheDJ (talkcontribs) 21:47, 28 September 2015 (UTC)
But the replacement is at least better than what was there before ;) Remember that this is not just about screenreaders. Readability for any person is also accessibility, and something like transliteration fills that need just fine. But transliteration for the purpose of fixing the screenreader, seems misguided to me. —TheDJ (talkcontribs) 21:50, 28 September 2015 (UTC)
But even 0.1% of readers is still a massive number. Screen readers have been around for some time now and the incompatibilities have not yet been fixed. It is flawed reasoning to dismiss the impairments of so many people by blaming assistive technology for not being better. Don't forget that JAWS can cost around $1,000 and updating to the latest version can be beyond the finances of many - not least those reading our content from less developed countries, who may have to settle for older technology. We have a known problem and we have the means to ensure that the maximum number of impaired visitors can access our content by keeping the symbol set simple. It's no more difficult than asking editors to keep the content readable by non-specialised visitors. Nobody would advocate using complex jargon in an article because it would put pressure on the schools to educate students better. --RexxS (talk) 14:56, 30 September 2015 (UTC)

Individual Engagement Grants[edit]

Apparently this is just a publicity contest where I'm penalized for not being able to write in English. Anyway, I'd like to make a Dab solver tool (+WP:DPL) for alt text. Automatic colorblindness is more uncertain (keep finding mistakes in papers), but we'd have something and hopefully more resources. — Dispenser 17:06, 27 September 2015 (UTC)

Dispenser. These are good ideas. But I'm afraid they might turn out to be much more complicated than they seem to be.
I've commented on alt text for example. Currently, most alt text that users write on Wikipedia is not great. Because it's a complicated issue that is also dependant on the mistakes of the MediaWiki software. Rather than aiming to increase the quantity of alt text, I think we should first try to improve quality and understanding. Dodoïste (talk) 14:42, 30 September 2015 (UTC)

Ordinals and superscript[edit]

Visual Editor has decided that ordinals must be superscripted. I usually see a couple of non-VE edited articles a day using superscripts and today there were 20+ VE articles. Before I file a bug ticket only to have the ticket dumped on the backlog queue to never see the light of day again, I'd thought I'd add accessibility info. Maybe that would help fix the problem. Do screen readers have issues with superscripted ordinals..... 2nd vs 2nd ? Bgwhite (talk) 06:38, 15 October 2015 (UTC)

I don't know of any screen readers that have problems with superscripts, but I'll ping @Graham87: to confirm. I'd be more concerned for older readers that the superscript css reduces the font size to 80%, which breaches our 85% minimum guideline at MOS:FONTSIZE, and that is 10.16px in monobook skin, which breaches the 11px minimum guideline there as well. I suppose I should also mention that MOS:ORDINAL, which is the agreed style for our articles, quite clearly states
--RexxS (talk) 18:29, 15 October 2015 (UTC)
Nope, it doesn't make a difference with screen readers. Graham87 02:43, 16 October 2015 (UTC)
@RexxS and Graham87: Thank you both. I'm aware of WP:ORDINAL as CheckWiki scans for these and I fix them. The problem is the MediaWiki developers don't care about bug reports. A group of us have identified over 30 issues with Visual Editor and Content Translator after we were encourage to do so at the last Hackathon in May. Both projects do not use the same Parsoid, so one has to report the same bug to both groups. VE group is more responsive to bug problems, Content Translator group just ignores us. You would think a bug where VE adds <nowiki> tags in refs (ie <ref><nowiki>{{cite web |.... }}</ref></nowiki> would be important to fix. Others bugs, such as Content Translator wikilinking dates, are a MOS issue on English Wikipedia and are not important. So, if the ordinal issue were accessibility rather than MOS, it might get fixed rather than be put on the backlog queue. Bgwhite (talk) 04:55, 16 October 2015 (UTC)
If an individual editor made such errors, persistently, after being advised not to, they'd be blocked, per WP:COMPETENCE, until they gave an undertaking to desist. Is there a comparable way we can gain the attention of those behind VE and CT? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 16 October 2015 (UTC)
Andy That is exactly what Magioladitis says every week after he gets frustrated with VE and CX. I wish I knew of an answer. FYI... They use CX as the abbreviation for Content Translator.
I don't have a problem with people not fixing their edits with VE. VE is supposed to do things correctly. CX is an entirely different mess of fail. Majority of people using CX are new and/or don't understand English. This is the most current article done with CX. It's a lovely piece of crap. There is also this, with <cite> tags (not templates) and whatever [[Paris|P]]<nowiki/>aris and [[Rome|Rom]]<nowiki/>a is supposed to be. Bgwhite (talk) 21:08, 16 October 2015 (UTC)


Wikipedia:Manual of Style/Mathematics#Using LaTeX markup recommends using association list formatting to fake a visual indentation for mathematics formulae. Do you all think that it's worth changing this (e.g., to something that provides the visual cue but uses {{indent}} or CSS formatting)? WhatamIdoing (talk) 18:26, 15 December 2015 (UTC)

Personally, I'd recommend using {{indent}} as it is a 'cleaner' implementation. No screen reader is going to be confused by spaces in the way that using a description list with a null term can turn into a nuisance for those users. Nevertheless, I expect screen reader users will be used to it by now. I'm rather more concerned with the recommendation in Wikipedia:Manual of Style/Mathematics #Alt text that "More complicated formulas, or formulas used in more technical articles, are often better off with the default alt text." I don't know what genius thought that up, but I fail to see who would be better off with the default alt text of "\int _{0}^{\infty }e^{-x^{2}}\,dx." (as used in the example in Wikipedia:Manual of Style/Mathematics #Using LaTeX markup) rather than something like "integral from 0 to infinity of e to the minus x-squared dx". I'm tempted to just remove that sentence. --RexxS (talk) 00:40, 16 December 2015 (UTC)
Maybe the alt text used to be better? I can't imagine anyone really proposing that reading out LaTeX code was a good idea. WhatamIdoing (talk) 18:47, 24 December 2015 (UTC)
It looks like <math display="block"> provides the indentation without adding odd spaces or list formatting. WhatamIdoing (talk) 18:49, 24 December 2015 (UTC)

Bot run for removing blank lines in list[edit]

I can create a list from dump files that show which articles have a blank line inside an unordered list. The list must be done in wikicode. AWB can fix the vast majority of these cases. AWB will only fix if the the blank line contains only a newline. Any spaces or tabs before the newline and AWB won't fix. Is this a good enough idea to get bot approval? I'm sure there will people who complain, so I'd like to get all my ducks in a row. Bgwhite (talk) 09:36, 24 December 2015 (UTC)

Sounds great to me. Thanks very much for helping out with this. Graham87 13:56, 24 December 2015 (UTC)
I would really love to have this done. I've been cleaning them up manually for years, and it doesn't seem to make a dent. May I recommend an explicit link to WP:ACCESS#Lists in the edit summary, since many people don't know about this issue?
Also, I'd like to see a bot that cleans up the use of semi-colons to make fake section headings (the last item in Help:List#Common mistakes). If the ;heading isn't followed by a :colon, then the semi-colon should be replaced by bold text. WhatamIdoing (talk) 19:01, 24 December 2015 (UTC)
I did a scan of 20% of the dump and there were 34,298 articles with a blank lines. I now can easily do scans for images in a list, fake headings made up of semi-colons and other variations. I think the images and fake headings will need to be fixed manually. Yes, I will be using an explicit link in the edit summary. When I moved TOCs to their proper spot for accessibility reasons, I did use explicit links. This still didn't stop the yelling, threats and being taken to ANI several times... main reason to get all the ducks in a row. Bgwhite (talk) 21:45, 24 December 2015 (UTC)
BRFA submitted at Wikipedia:Bots/Requests for approval/BG19bot 9 Bgwhite (talk) 23:57, 28 December 2015 (UTC)