Wikipedia talk:Manual of Style/Accessibility

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
WikiProject Manual of Style
WikiProject iconThis 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 iconThis 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 iconThis 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.
 


Font size wording[edit]

Our guidance on font size currently reads:

Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that <small>...</small> tags, and templates such as {{small}} and {{smaller}}, should not be applied to plain text within those elements.

it's obviously not optimal, as editors have made amendments to it recently. The choice of "plain text" to describe the default text size for the infobox is not great, and Jonesey95 has tried substituting "already-reduced", which I've reluctantly reverted because I've had more than one protracted argument with editors who were simply unaware that the default font size is already reduced in an infobox.

Just for background, an infobox reduces its default font size to 88% of the default font size for the page. It also increases its main header to 125% of that (i.e. 110% of the default font size for the page). That means that, in theory, an editor could apply {{small}}, etc. to part of the text appearing in the main header (even though I can't think of sensible case for that). So the guidance needs to prohibit reducing text size on all of the elements of the infobox that are at default size – what the guidance currently calls "plain text". The only formulation I can come up with is:

Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that, within those elements, <small>...</small> tags, and templates such as {{small}} and {{smaller}}, must not be applied to text that is at the default size for the element.

That still feels unwieldy, so are there any wordsmiths who can re-encapsulate the guidance to make a better job of it? --RexxS (talk) 14:49, 1 March 2019 (UTC)

it's obviously not optimal, as editors have made amendments to it recently. Which could be interpreted to mean those amendments are what made it not optimal. I don't think that was your intent. ―Mandruss  15:18, 1 March 2019 (UTC)
I would argue that the same editors who are unaware that the default font size is already reduced in an infobox would be unaware of what text is at the default size for the element. The average editor has no grasp of the underlying technical concepts, so anything we say will be problematic. I'm inclined to say "don't use small in these elements, period"—which is what the first sentence effectively says anyway. If some knowledgeable editor feels the need to deviate in some exception case, using small for something not already reduced, they can do so with a hidden comment explaining their rationale and justifying the exception. After all, all guidelines are subject to exception by definition, despite the fact that they are usually treated as absolute. ―Mandruss  16:21, 1 March 2019 (UTC)
The reason for my admittedly awkward change stemmed from this discussion, and from a note by Galobtter in the April 2018 RFC on small text in infoboxes that {small} etc can be used in titles and in |above= without the size getting below 85%. So shouldn't be deprecated there. As for editors using {{small}} in |above=, which RexxS couldn't think of a sensible case for, I believe that I have seen |name= and |native_name= jammed into |above= in more than one infobox, with the native name rendered smaller than the name, but I am unable to dig one up right now. It's not pretty, and I'm not saying it's sensible, but it usually "works" and is MOS-compliant, more or less.
I support RexxS's revised wording. – Jonesey95 (talk) 00:48, 10 March 2019 (UTC)
I'm with Mandruss: just say no smaller text in elements where (most) text is rendered smaller to start with. Exceptions can be debated on a per-article basis. It's very possible a significant number of editors aren't explicitly aware of which parts of, say, infoboxes are rendered at the default size for that element and which aren't... I certainly wasn't until reading through this discussion—and that these parts wouldn't techncially be restricted from being rendered with <small>...</small>. And as several have mentioned, it would seem like a very rare case where someone would be using two or more text sizes in the same rendered-larger section of a rendered-smaller element. Arrgh... I can see why people have struggled on how to word this! —Joeyconnick (talk) 22:56, 16 March 2019 (UTC)

Table colors for film ratings[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see: Talk:Motion picture content rating system#RfC: Should we install a color scheme with 9 colors in the comparison table?.

Salient comment: "A WP:Local consensus cannot opt out of policy or the MOS, no matter how long ago the last RFC was. We have clear guidelines on which color combinations are effective for color-blind users." I'm not a WCAG colors expert but some of what's being proposed looks wrong to me (insufficient luminosity/contrast differences).  — SMcCandlish ¢ 😼  06:21, 2 April 2019 (UTC)

@SMcCandish:This website's color scheme will be better, maybe.Zenkaino lovelive (talk) 13:18, 2 April 2019 (UTC)
@SMcCandish:I used this Chrome-extension program, and I made a sample table when color-blind users see in my sandbox. Original source:[1] Me:Protanopia Deuteranopia Tritanopia This color scheme is by this website's color scheme.ABOChannel (talk) 09:52, 3 April 2019 (UTC)
@Zenkaino lovelive and ABOChannel: Please do not split the discussion. SMcCandlish's post above is a notification, in line with WP:MULTI. --Redrose64 🌹 (talk) 20:51, 3 April 2019 (UTC)

Default link color[edit]

I'm trying to understand why the default link color I see on Wikipedia is #2A45AC which does not appear in the table at Wikipedia talk:Manual of Style/Accessibility/Colors. Any ideas? I'm using the Vector default skin. --Gonnym (talk) 11:02, 6 April 2019 (UTC)

Which table is that? I see several concerning Doctor Who episodes, but none about link colours. Indeed, the only mention of link colours is in this thread. --Redrose64 🌹 (talk) 18:13, 6 April 2019 (UTC)
@Redrose64: I think Gonnym meant Wikipedia:Manual of Style/Accessibility/Colors (the talk page is redirected to here).
@Gonnym: That's odd because when I log in with a vanilla, unmodified account, the default link colour shows up as #0645AD in the inspector (both FF66 and Opera 58), and I've confirmed that by taking a screenshot and examining the colour in an image editing program. Anybody have any thoughts? --RexxS (talk) 19:11, 6 April 2019 (UTC)
Yes, thank you RexxS, I meant that page and mistakenly linked to the talk page. I used ColorPicker Eyedropper extension for chrome, but when I inspected the element via the Chrome console I got your value. No idea why the extension "sees" it as a different color. --Gonnym (talk) 19:25, 6 April 2019 (UTC)
The default colours depend on skin and browser? Walter Görlitz (talk) 19:31, 6 April 2019 (UTC)
@Walter: they definitely depend on skin (I use monobook on my main account and it's noticeably different). They shouldn't depend on browser, but there's never any guarantee of how some unusual browser might behave, so I try to give full info just in case.
@Gonnym: I think #2A45AC is actually quite close to #0645AD, just a tiny bit redder. I wonder if the ColorPicker Eyedropper caught a piece of antialiased text that had a slightly modified colour? --RexxS (talk) 19:36, 6 April 2019 (UTC)
If that's the case, then maybe. I tried inspecting various "blue" link text to get the #0645AD value and got different results of blue. In this page, the box at the top that says "This is a talk page. Please respect...", when I inspect with the color picker the "a" of "page" it gives me that value. --Gonnym (talk) 19:55, 6 April 2019 (UTC)
If it is an anti-aliasing effect (and a yellowish background will tend to make one side of the character redder and the other greener), then you can try increasing the zoom as high as you can to minimise your chance of picking up a modified pixel near the edge of a character. Cheers --RexxS (talk) 20:41, 6 April 2019 (UTC)

This makes me angry[edit]

Have you seen these comments? --Redrose64 🌹 (talk) 21:43, 8 May 2019 (UTC)

I agree that broken screen readers should be fixed, but we accommodate things worse than that, so it's not a problem for me to make allowances for people who have no other choice. Walter Görlitz (talk) 21:49, 8 May 2019‎ (UTC)
It's more that MediaWiki is broken, as I see it. But not easy to fix ... Graham87 09:29, 9 May 2019 (UTC)
One of the problems we face is the unwarranted assumption that MOS only applies to articles, but that's simply not true. The MOS covers three broad areas: documenting conventions; guidance on functionality; and guidance on accessibility. It is reasonable to assume that the first, and perhaps the second, have their greatest applicability in mainspace, but there can be no doubt that the guidance the MOS gives to help make our encyclopedia accessible to all must apply to every page. We need to advertise that more forcefully. To that end, I've just added a brief paragraph to the lead of Wikipedia:Manual of Style to try to make the point. Please feel free to improve it. It may need some support to establish that it is the consensus viewpoint. --RexxS (talk) 10:02, 9 May 2019 (UTC)
And not unexpectedly, it has been reverted without recourse to the talk page where I had already opened a discussion. I'd be grateful for further opinions at Wikipedia talk:Manual of Style # Scope of accessibility guidance. --RexxS (talk) 16:27, 9 May 2019 (UTC)

Canadian legislative layout and accessibility[edit]

A change has been made at Legislative Assembly of British Columbia based on a discussion at Talk:Legislative Assembly of British Columbia. It relates to part colours, link colours and other issues related to MOS:ACCESS. Walter Görlitz (talk) 15:19, 13 May 2019 (UTC)

Use of the horizontal rule[edit]

The horizontal rule has been used for sometime now to combine episodes in TV episode lists, for example episode 1/2 of Terra Nova (TV series). Last night an IP changed the code to combine the episodes,[2] which is an issue that even went to RfC so I reverted. This resulted in the IP making this edit stating "In that case, fix massive accessibility issue and tag unruly summary" in his edit summary. He hasn't made clear what the issue is but it seems to be use of the horizontal rule. However, I can find nothing in MOS:ACCESS, or in the talk page archives about this issue so my question is, should we be using horizontal rules or not? If so, then this affects many more than the mentioned article and will need to be addressed by the TV project. I've opened a related discussion at WT:TV#Use of the horizontal rule regarding this. --AussieLegend () 07:24, 28 May 2019 (UTC)

Rowspan[edit]

Lately there has been a trend deprecating the use of rowspan in filmography tables for biographical articles (for multiple roles in the same year) for accessibility reasons. However, though I believe this falls under the guidelines at Wikipedia:Manual_of_Style/Accessibility#Tables, there is no specific mention there of rowspan. If avoiding rowspan is a valid action, it would really help to have somewhere specific to refer editors who challenge it. I'm not sure if this is happening in other types of articles.— TAnthonyTalk 19:45, 28 May 2019 (UTC)

Happens in TV and discography articles as well (and I'm sure in most other places). --Gonnym (talk) 20:04, 28 May 2019 (UTC)
Please have a look at Graham87's comments in Wikipedia talk:WikiProject Accessibility/Archive 6 #Row spans in tables. Screen readers have got better at dealing with rowspans since I wrote User:RexxS/Accessibility in 2010 to examine the issues raised by rowspans in the Opera and Lynx browsers. Rowspans are not the deal-breaker that they used to be, but it's still kinder to screen reader users if we avoid them where we can. Doing so would certainly make a table more easily navigable, and would probably improve its readability for anyone using any assistive technology. Nevertheless I'd be loathe to try to use MOS to prohibit rowspans, because of the inherent inertia in many WikiProjects who will want to do things "the way we always have". We're much more likely to get accessibility improvements across the wiki in the long term by raising awareness and persuading editors of what is best practice in these sort of cases. --RexxS (talk) 20:55, 28 May 2019 (UTC)

Use of scope="row" for a colored cell with no text[edit]

I noticed that some tables, like the reception one at Agents of S.H.I.E.L.D.#Reception use !scope="row" on a colored cell with no text. Is this proper use? --Gonnym (talk) 15:17, 30 May 2019 (UTC)

@Gonnym: Not really. The whole point of marking a row header cell with scope="row" is to ensure that a properly configured screen reader will read out the text of that cell along with the column header before the contents of a given data cell in that row when navigating into that data cell. So if there's no text in the row header, there's nothing for the screen reader to read out, which kinda defeats the purpose of the row header Face-sad.svg.
On the other hand, it's not a big problem for the screen reader; it's just not as good as it could be. We do at least have people attempting to mark up row headers properly, and I'd hate to discourage them.
Anyway, I've changed to row header to be the numeric column now, so that a screen reader navigating down the 'Rank' column might hear "1, Rank, 43", then "2, Rank, 76", and so on, which is a lot better than not hearing the season numbers each time. If it gets reverted, I'm not going to edit-war over it. --RexxS (talk) 23:35, 30 May 2019 (UTC)