Wikipedia talk:Manual of Style/Accessibility

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style    (Inactive)
WikiProject icon This page was within the scope of WikiProject Manual of Style, a project which is currently considered to be inactive.
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.
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.

{{color sample}} and accessibility[edit]

Could somebody with more HTML/colour experience than I have weigh in at Talk:Dust Bowl#A map, at long last regarding the accessibility problems with {{color sample}}? Thanks. Graham87 15:55, 15 January 2017 (UTC)

Template:Episode table print access issue[edit]

The use of colored backgrounds for purely cosmetic purposes when {{Episode table}} is used should be discouraged and forbidden when the background is darkened to the point that the descriptive text is forced to white. As when one prints the page readability can suffer due to printing being limited to either CMYK or grayscale only. An alternative would be to have the print export view disable CSS elements but that could affect the article layout. (talk) 01:41, 24 January 2017 (UTC)


comments at Talk:Upper East Side#listgaps are welcome. Frietjes (talk) 16:03, 24 January 2017 (UTC)

Listgap: a proposal[edit]

@TheDJ, Psiĥedelisto, Graham87, and RexxS:

The problem with listgaps, as I understand it, is that blank lines, which are often meant to provide some visual clues to list structure,

  1. mess up the numbering of ordered lists and
  2. really mess up the organization of the list and sublists for screenreaders, because they affect the semantics in ways that aren't visible to sighted users of unordered lists.

But the HTML <br> tag can produce the same sort of visual break without introducing any actual (as far as code can tell) blank lines. And so it occurred to me that it might be wise to suggest this tag in MOS:LISTGAP as a way to add gaps for visual readers without hindering screenreader users. I started to draft an alternative version of that section in my userspace, and realized further that even without mentioning <br>, the section would benefit from showing the display of each acceptable (‍YesY‍) and not acceptable (‍N‍) example and not just the wikicode.

Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists says

Do not separate list items with line breaks (<br>). Use {{plainlist}} / {{unbulleted list}} if the list is to remain vertical; or consider {{flatlist}} / {{hlist}} if the list could be better rendered horizontally (in-line) as described in the following two sections.

But I believe that that refers to using <br> to visually simulate a vertical list, and for exactly the same reason that I'm suggesting it to visually simulate a gap: that it has a visual effect but not a semantic one.

My draft is in User:Thnidu/Draft: Safe blank lines. I added new paragraphs in boldface, then (facepalm) realized that that probably doesn't help anyone using a screenreader, so I wrapped my additions in plaintext labels "[BEGIN ADDED]" and "[END ADDED]". I haven't expanded all the examples, but if people think this is a good idea, the additional expansions would be pretty obvious to implement.

Please {{Ping}} me to discuss. --Thnidu (talk) 02:10, 1 February 2017 (UTC)

  • @Thnidu: There are a couple of problems with your page: 1) you forgot to add the <br> to your last example, and 2) even adding it makes no difference to the display on my screen. However, adding two <br>s does add extra space. I suspect that different browsers will interpret <br> differently. — Gorthian (talk) 03:27, 1 February 2017 (UTC)
    • Gorthian, oy, and thank you. Looks like I had the right idea, roughly, but didn't get it quite right. And 2 breaks DOES work indeed. I needed them between my 2 star answer here and Graham87's 2 star answer to me, which I think should've been 1 star with a break or two, rather than 2 star, bc it wasn't an answer to you. ... Gotta go. --Thnidu (talk) 04:58, 1 February 2017 (UTC)

    • @Thnidu: The idea sounds reasonable to me in general, but <br/> would be preferred these days. The part of the accessibility guideline about not separating list items with line breaks refers to their use in tables to separate list items instead of semantically correct list markup. Also, your ping didn't work because you added the mentions onto your post; let me do it for you (excluding myself): @TheDJ, Psiĥedelisto, and RexxS: Graham87 03:42, 1 February 2017 (UTC)
      • @Graham87: Uhhhh... yeah. Thanks. I think I'm out of facepalms for today. --Thnidu (talk) 04:58, 1 February 2017 (UTC)
      • @Graham87: About your observation
        The part of the accessibility guideline about not separating list items with line breaks refers to their use in tables to separate list items instead of semantically correct list markup.
        Yes and no. The part I quoted, Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists, is about lists within tables. But the section I cited first, MOS:LISTGAP (shortcut to Wikipedia:Manual of Style/Accessibility § Lists), which my draft text is based on, is about lists in general and doesn't even mention tables:
        Do not separate list items by leaving empty lines or tabular column breaks between them. This includes items in a description list (a list made with a leading colon) or an unordered list. Lists are meant to group elements that belong together, but MediaWiki will interpret the blank line as the end of one list and start a new one. These excessive double line breaks also disrupt screen readers, which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Improper formatting can also more than triple the length of time it takes them to read the list. Likewise, do not switch between list marker types (colons, asterisks or hash signs) in one list, unless embedding lists starting at the highest level.
        I should have referred to that section in the first place, not to Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists. --Thnidu (talk) 06:17, 1 February 2017 (UTC)


There's some accessibility issues for the Chart module. We need some focus on CSS override and print-ability. — Dispenser 05:55, 6 February 2017 (UTC)

Help with {{TOC limit}}[edit]

Maybe I'm being dumb, but can someone advise how to apply this template without inadvertently setting the Table of Contents above the Lead? I just experimented at Revolver (Beatles album), ended up with this. Thanks, JG66 (talk) 16:47, 7 February 2017 (UTC)

@JG66: First, the {{TOC limit|3}} must be the last item in the lead section - you were putting it between infobox and introductory text. The easiest way to do this is to first ensure that you have "Add an [edit] link for the lead section of a page" enabled at Preferences → Gadgets. Then edit the lead section of the article, and in the edit box, go to the very end of the text. Add the {{TOC limit|3}} on a line of its own, and save. --Redrose64 🌹 (talk) 17:05, 7 February 2017 (UTC)
@JG66: In short, don't put it above the lead. :D --Izno (talk) 17:07, 7 February 2017 (UTC)
  • Ah, many thanks to you both. I coulda sworn I first tried it, in preview, with the template below the lead … Anyway, just as well I opened my request here with: "Maybe I'm being dumb …" Cheers! JG66 (talk) 17:19, 7 February 2017 (UTC)

Columns for references[edit]

Hello, all. I re-started a discussion at the reflist template a little while ago, to see if we could improve accessibility on different screen widths/font sizes. I think that RexxS has a solid solution in that template's sandbox. It's a very widely used template, so I really don't want to screw this up or have to make more than one change. If there's anything else that ought to happen here, or if you have any thoughts on the change, could you please join the discussion over there and let us know? Thanks, WhatamIdoing (talk) 21:16, 20 February 2017 (UTC)