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.

Complex tables and Wikipedia[edit]

You are invited to join a discussion: Complex tables cannot be made accessible in Wikipedia and what to do about it Thisisnotatest (talk) 21:13, 7 June 2015 (UTC)

missing text[edit]

Under the "Bulleted vertical lists" section, at the end it states, "Do not separate list items with line breaks (<br>). Use one of the following methods." Problem is, it doesn't give any following methods. Bgwhite (talk) 23:37, 8 July 2015 (UTC)

The "following methods" are the sections following, i.e. Unbulleted vertical lists and Horizontal lists. In other words, the guideline advises replacing list items separated by <br> with: {{plainlist}}/{{unbulleted list}} if the list is to remain vertical; or consider {{flatlist}}/{{hlist}} if the list could be better rendered horizontally (in-line). I'll try to clarify that. Feel free to tweak if you can improve it --RexxS (talk) 00:32, 9 July 2015 (UTC)

Table summaries[edit]

FYI: Pointer to relevant discussion elsewhere

More input is sought at Wikipedia talk:WikiProject Accessibility#Expert review needed.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  15:36, 18 July 2015 (UTC)

list gaps and over styling[edit]

any suggestions about what to do about [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... ? Frietjes (talk) 17:14, 26 July 2015 (UTC)

Just revert, especially when accessability is compromized. Wikipedia is not a styling playground. -- [[User:Edokter]] {{talk}} 17:28, 26 July 2015 (UTC)
Concur. If any of those tweaks has a real purpose it should be introduced, with consensus, individually. That looks like a spree of sandboxing.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:07, 27 July 2015 (UTC)
User:SMcCandlish, User:Edokter, it continues, some help with reverting would be appreciated. Frietjes (talk) 14:10, 11 August 2015 (UTC)
Has anybody approached Spartan7W? Alakzi (talk) 14:13, 11 August 2015 (UTC)
left messages on the respective talk pages. Frietjes (talk) 14:29, 11 August 2015 (UTC)
Thank you. Alakzi (talk) 14:37, 11 August 2015 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Is there any reason nobody notified me ahead of time?@Frietjes: All these are on my watch list, I didn't see any talk messages. That would have been nice. Wikipedia is full of styling, almost all navboxes for universities and other institutions of higher learning have a colored style. Below linked are examples of these. They have been this way for a long time, with no objection. I see no injury done by styling, and the styling I used was not arbitrary, each was representative of the symbols of their respective jurisdictions.

Template:Ivy League, Template:Princeton, Template:USNA, Template:Patriot League navbox, Template:Yale, Template:Harvard Spartan7W § 14:42, 11 August 2015 (UTC)
none of those are related to U.S. politics or history. Frietjes (talk) 14:45, 11 August 2015 (UTC)
Please tell me what difference that makes. See Template:Popes, Template:Catholicism, and other Catholic-related templates. If there is a legitimate issue with my styling, that styling is also wrong. Spartan7W § 14:47, 11 August 2015 (UTC)

Minor accessibility point discussion[edit]

I've made an accessibility argument (with regard to partially-visually-impaired users of GUI browsers with large font sizes), at MediaWiki talk:Common.css#Compensate for italic lean. Someone expressed skepticism about this, so it's probably best if some accessibility specialists have a look at it; it's possible I'm arguing for a distinction that doesn't need to be drawn.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  22:29, 29 July 2015 (UTC)

That discussion is still running. Some additional input would be useful.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  14:34, 11 August 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)


I've reverted the rather WP:POINTy removal of the parenthetical wording from the colour-section's hatnote "This section is about the use of colors in articles (though the advice on contrast ratios is applicable more generally).". This, being part of WCAG, quite clealry applies to al web content, and there are incoming links from relevant discussions.

As noted at the head of the page:

The WMF's Non discrimination policy... "is approved by the Wikimedia Foundation Board of Trustees to apply to all Wikimedia projects. It may not be circumvented, eroded, or ignored by local policies". and says: "The Wikimedia Foundation prohibits discrimination against current or prospective users... on the basis of... disability".

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 20 September 2015 (UTC)

I reverted without seeing you had started a thread, though I did intend to start one anyway. It is not disruption to prove a point. This is a MOS page which is for the style of articles. If we were to keep inserting tidbits of global policy into the article-specific MOS it would become very unwieldy. I suggest you start a separate guideline if you want to globalise the sense of WP:COLOUR.
I will proceed to notify the relevant WikiProject of this discussion. BethNaught (talk) 15:58, 20 September 2015 (UTC)
This page and other parts of the MOS refer to other non-article matters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 20 September 2015 (UTC)
It makes little sense to split off color ratio policies that apply globally to another page when around 10 words here suffices. The measure preventing an unwieldly policy is common sense, and we should exercise it here. ~ RobTalk 16:18, 20 September 2015 (UTC)
The Manual of Style obviously does not apply only to article space. It is clear that templates must also conform to the MOS as they can produce output within articles, so require identical care in making them accessible. The same consideration applies exactly to the module namespace. In fact, since we expect all of our namespaces to be accessible to readers and editors with impairments, there is a clear case for applying sensible guidance on accessibility to all namespaces. Is there any reason why a user's talk page, for example, should display with a combination of foreground and background colours that would make it unreadable to someone with a common colour-blindness? --RexxS (talk) 16:34, 20 September 2015 (UTC)
One can start to split hairs on what is or isn't an article. Disambig pages are not articles, but reside in articles space. Templates show up in articles, but are not articles. In the end, shouldn't templates, disambig pages and talk pages be "content that anyone can use, edit, and distribute"? (quoted material from five pillars). MOS:ACCESS and specifically WP:COLOUR are one of the very few guidelines that apply on any Wikipedia page. I can't think of anything in WP:COLOUR that would not apply to talk pages, templates or help pages. Bgwhite (talk) 21:14, 22 September 2015 (UTC)
@BethNaught: There is nothing that requires MOS pages to apply just to articles as you seem to suggest. Since WP:ACCESS was merged into the MOS not so long ago, it has been accepted that global policy related to accessibility is documented here. What possible advantage could there be in re-creating a separate guidance page just to document global accessibility policy? --RexxS (talk) 03:30, 23 September 2015 (UTC)
OK. Given that the merge you mentioned appears to have happened in 2010, well before my time, I was not aware of it, but if that was a consensus decision then I'm entirely OK with this. As I say, the lead of WP:MOS does mention articles in particular; however, if the general understanding is that components can be global, I can live with that. I hope you understand that, given it's not my personal feeling on how the MOS should work, I wanted to check that Andy Mabbett's change actually reflected community consensus. Thanks all. BethNaught (talk) 06:43, 23 September 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @BethNaught: It's worth noting that WP:ACCESS is kind of a weird guideline because it derives its "authority" from a WMF policy that cannot be changed via local consensus. No matter what we write in the guideline itself or decide as a community, inaccessible colors cannot be used anywhere on the project where alternatives exist, as the WMF's non-discrimination policy is clear that we must make the site accessible to all potential readers whenever feasible. That policy is preceded by a statement that local consensus cannot override or erode it in any way. It's always tricky where we have WMF policies conflict with our preferred dispute resolution method, but this is an area where consensus has a much lesser role than it does elsewhere. ~ RobTalk 07:27, 23 September 2015 (UTC)

Referral to un-helpful category Image insertion templates[edit]

The Text section of this project page contains the following instruction:

Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is {{}}; see Category:Image insertion templates for more.

However, Category:Image insertion templates appears not to have any content and in fact bears the message "Note: This category should be empty."

So how does one get a handy list of Image insertion templates? And would whoever knows please be so kind as to update that item? Or else fix Category:Image insertion templates so it shouldn't be empty and isn't, if that is the actual problem.

Thisisnotatest (talk) 06:40, 23 September 2015 (UTC)

Thanks for the note; I've fixed it. Graham87 14:59, 23 September 2015 (UTC)

Layout table clarification[edit]

I believe a table such as

COL Colonel LT Lieutenant SGM Sergeant-Major CPL Corporal
LTC Lieutenant Colonel 1LT First Lieutenant 4SG Fourth Sergeant PVT Private
MAJ Major 2LT Second Lieutenant SGT Sergeant QM Quartermaster
CPT Captain CNT Cornet 3CPL Third Corporal AQM Assistant Quartermaster

straddles between being a data table (abbreviation and value) and a layout table (using multiple columns to save space). My reading is that this is not accessible, but it's not clear from the section on layout tables whether this is the case. Could someone clarify? Thisisnotatest (talk) 09:12, 26 September 2015 (UTC)

It's a layout table, so shouldn't be marked up with scopes as that will confuse screen readers - and they are meaningless in the way they are shown; e.g. 'Major' seems to be a row header for 'Second Lieutenant', which is nonsense. It's also a mess on mobile devices as there are eight fixed columns, so I'd recommend avoiding this sort of markup.
For this sort of common problem (multiple columns), you would be best using a template that simply allowed the content to flow inline, like this one I made as a demo:
Lieutenant Colonel
First Lieutenant
Second Lieutenant
Fourth Sergeant
Third Corporal
Assistant Quartermaster
A screen reader would simply read those linearly - there's no real advantage in having a table when the data is in pairs. This kind of layout re-flows gracefully as you resize the window (try it!), and should be just as readable for a sighted visitor as the original table. Does that help? --RexxS (talk) 22:45, 26 September 2015 (UTC)
For the record, "Major" is not a row header – it's using the scope attribute on a td element, which is deprecated in HTML5. nyuszika7h (talk) 10:16, 27 September 2015 (UTC)
What would be the purpose of "scope", if it were used correctly? — Arthur Rubin (talk) 19:59, 27 September 2015 (UTC)
For td elements, there is really no point, as those are either headers improperly marked up as td, or normal data cells in which case scope should not be used at all. For headers, it's used to specify whether they're column or row headers, which is most useful if they are not in the first row or column, though being explicit is better, and scope="row" is also used for the plainrowheaders style on Wikipedia. nyuszika7h (talk) 20:16, 27 September 2015 (UTC)
@Nyuszika7H:, if you mark up any cell with scope (as is done with the Major cell) then a screen reader will usually treat it as a row header, regardless of what HTML5 says it is in theory. So yes, it is a row header as far as most screen readers are concerned and JAWS, for example, is likely to announce it as the row header for cells to the right of it when navigating in table layer mode. As usual, I'd recommend reading to get an insight into what is happening. @Arthur Rubin: with modern screen readers the user can choose "table layer mode", which allows them to navigate from cell to cell in any direction, instead of being forced to read the entire table left-to-right, top-to-bottom (as used to happen). In that mode the user can have the column and row headers spoken before the data in the cell, e.g. going down the Category column at List of accolades received by The Artist (film) #Accolades, one might hear "Academy Award","Category","Best Picture"; then "Academy Award","Category","Best Director"; and so on. It's well explained in the link I gave above. However, older screen readers were inconsistent in how they would decide on the row header: some would simply use the first cell in the row, many others would override that if a different cell were marked up as <td>...</td>, and yet others would give preference to a cell marked as scope="row". Similar issues would affect column headers. So to maximise the chance of any particular screen reader using the cell we designate as the row/column header, we give the advice to mark up the column and row headers with both '!' and 'scope'. Redundancy never makes the issues worse and usually gives the desired result, even with older software. Hope that helps. --RexxS (talk) 21:32, 27 September 2015 (UTC)

So it looks like Jaws correctly handles scope markups. What about other readers? Anyway, thanks for the explanation on the included table; perhaps removing scope from that table is the best move? Thisisnotatest (talk) 05:19, 28 September 2015 (UTC)

Sadly there are far too many screen readers (and versions of the same reader) to give a general answer - you only have to look at List of screen readers to get an idea of what the range is. To date we haven't agreed as a community to only support a limited range (e.g. the most popular, or versions less that three years old), so my advice is to design for the worst case, so include using both '!' and 'scope' on all data tables, as described at WP:DTT. Layout tables definitely should not have cells marked as headers (see F46), so the original table should not have '!' or 'scope' markup. The other options would be to reformat the data into a data table with 2 columns and 16 rows (plus a header row for the columns such as "Abbreviation", "Meaning") (which would leave a lot of white space on a wide screen); or to make four separate data tables with proper headings and place them inside a layout table of 4 columns and 1 row (which would be horrible markup and would not work on small screens). --RexxS (talk) 20:04, 28 September 2015 (UTC)

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)

Bold markup in pseudo-headings[edit]

It is a real improvement for screen readers when we replace pseudo-headings with real headings (usually ;Notes and ;Bibliography or similar in the ==References== section, when Harvard-style referencing is used). However editors often object to the cluttering up of the Table of Contents by these relatively 'trivial' level-3 headings. Often we can't use {{TOC limit}} because there are other, 'important', headings at level-3 that ought to be in the TOC. In such cases, the best compromise has been found to mark up the pseudo-headings as bold. This delivers the visual distinction that the editors crave, while creating a minimal annoyance to screen reader users (they can have announcing bold/italic/etc. turned off). That means the screen readers can't navigate directly to the sub-headers (nor can anyone else!) because they are not marked up as headers, which is sub-optimal, but it may be the best we can achieve when the article editor is determined to achieve a particular visual appearance. --RexxS (talk) 21:57, 26 September 2015 (UTC)

In such cases, it would be better to have {{TOC limit}} fixed, and retain the use of proper, accessible and semantic heading markup. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:59, 27 September 2015 (UTC)
Indeed it would be better. But the effort required to achieve that in the face of determined opposition makes the improvement not worth the pain involved. Life's too short. --RexxS (talk) 20:57, 27 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)