Wikipedia talk:Manual of Style/Accessibility/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 10

Text size

As a person with good corrected vision, I find the {{Reflist}} text too small for comfortable reading, this must be worse for those with more serious visual problems. The accessibility guidelines have nothing to say on type size, perhaps something should be added? Rich Farmbrough, 10:07 18 February 2008 (GMT).

Just my thoughts here. The difference between the main text and text in {{Reflist}} looks like about two points. On my computer the text in the references of Road appears to me the same size as text on the front page of the Seattle Times, so I don't see a problem. I think most people expect to see references supplied in font size that is smaller then the main text, it is what we usually see in print and bound books. I should also add that I have played with just about all my computer and browser settings for font size, so what I am seeing may not be the same as what a user on a virgin system is seeing. Jeepday (talk) 15:03, 18 February 2008 (UTC)

Currently, mediawiki:common.css is defining .references-small { font-size: 90%;}

I'd thought there was some agreement somewhere that 92% was the smallest we should use anywhere, but I can't find the discussion I'm looking for currently. (See Template:FootnotesSmall and its talkpage for a bit of discussion about 92%)

However, as long as we're allowing text to be resized by the user manually, such that they can increase fonts with their browser whenever needed (ctrl-+ and ctrl-− in firefox), I don't think we need to change anything drastically. Because user defaults (browser program/settings, OS font settings, monitor size/screen resolution) vary so drastically, we can't be perfect for everyone. -- Quiddity (talk) 18:59, 18 February 2008 (UTC)

Rich just added the issue that I wanted to add. The Wikipedia is the only web site I regularly visit which has routine and ubiquitous use of small font sizes for matter that I want to read. I'm not going even attempt to reverse the decisions to use small fonts, but could there been a global setting in user preferences for minimum font size displayed (i.e. the floor of the font size). This would enable a person with a slight impairment such as myself to set it to 10 points, while people with greater impairment could set it to 12 or 14 points.

To points raised above: The problem really isn't in the browser but in the Wikipedia renderer (or any web page with combining extra large and extra small fonts). The comparison to printed media is not accurate: the printed page is analog, and monitor legibility of smaller fonts to the visually impaired doesn't scale in the same way. patsw (talk) 20:18, 18 February 2008 (UTC)

Note: I was comparing display font on the web pages Road and Seattle Times, Not print to web Jeepday (talk) 20:29, 18 February 2008 (UTC)

It seems to me that the only reason we use small fonts is to look like traditional designed-for-paper scholarly works. Rich Farmbrough, 20:42 18 February 2008 (GMT).

And to reduce the size of massive refs sections, eg William Gibson#References, which seem to bug some people. Personally, I'm often tempted to replace {{Reflist}} with <references/>, but don't simply to avoid low-priority arguments/reversions. -- Quiddity (talk) 21:37, 18 February 2008 (UTC)

Rather than switch conventions (a very low-priority, but very argumentative argument waiting to happen), it may be useful to know that an individual can fix this easily (just for them). One just adds

 .references-small { font-size: 100%; }

to your Special:Mypage/monobook.css.

Perhaps it might be worth gathering some similar options and including them in the preferences as a simple "visually impaired" setting. Personally, I've always used Firefox's minimum font size to globally fix this problem. It makes some sites look ugly, but honestly, they looked uglier before. JackSchmidt (talk) 22:25, 18 February 2008 (UTC)

Small text addition to guideline?

Can we add a line to this page about using small size text? It's a hindrance to people with poor eyesight, and even those with good eyesight (read me) find it a turn-off. Matthewedwards (talk • contribs • email) 06:45, 26 August 2008 (UTC)

Yes please. I've been asking for the same thing everywhere for ages. (Lots of relevant discussions at MediaWiki_talk:Common.css/Archive_4#Font_size_reduction and Template_talk:Reflist#Font_size and Template_talk:Reflist/Archive_2008#Font_size and somewhere:infobox and further up this very page at Wikipedia_talk:Accessibility#Text_size and probably lots elsewhere.) -- Quiddity (talk) 07:27, 26 August 2008 (UTC)

Infobox size doesn't bother me. Everything that is an infobox should be in the main prose of the article as well. References.. meh.. <references/> doesn't make them small, and should be used for articles where there's fewer than 20 references, I think. {{Reflist}} I suppose makes them smaller so the page doesn't take too long to load when there is a lot of references. Matthewedwards (talk • contribs • email) 07:59, 26 August 2008 (UTC)

Font size has no effect on page loading time. Using many citation templates will make the page slower to load; for a dramatic example of this, see United States. Graham87 11:16, 26 August 2008 (UTC)

Oh. OK. And since posting that I looked at those links, and I agree - reflist should either be made 100% or 95%. Matthewedwards (talk • contribs • email) 16:27, 26 August 2008 (UTC)

Is your complaint about the default font size (which is something you can easily change on your own computer), or about using different font sizes? WhatamIdoing (talk) 19:58, 26 August 2008 (UTC)

My complaint is about articles where the font size has been forced to be smaller. It often appears in lists and tables, such as at All-NBA Team. I haven't actually seen it used in prose. When I read the discussions provided by Quiddity, I am even more convinced that we need a line to say "no small fonts". And I shouldn't have to change my default font settings or add a script to my monobook, or anything else. The majority of our readers are not logged in, and they don't get to do that. Matthewedwards (talk • contribs • email) 03:41, 27 August 2008 (UTC)

Our implementation of <blockquote></blockquote> makes everything 85% too. Damned hard to read. (I'm making a note at MediaWiki talk:Common.css#Font sizes) -- Quiddity (talk) 04:26, 27 August 2008 (UTC)

Might you, however, encounter this problem on other websites occasionally? And might you be inclined to solve all your problems at once, in about ten seconds, instead of trying to reform each webpage one by one?

In Safari (browser), you go to Preferences>Advanced>Universal Access and tick the "Never use font sizes smaller than (fill in the box)" button. In Firefox (browser), you go to Preferences>Content>Font & Colors>Advanced and set the "Minimum font size" in the menu. I don't run the Microsoft browser, but I assume that similar features exist there, too. WhatamIdoing (talk) 05:30, 27 August 2008 (UTC)

Only on badly designed websites ;) Rather than just fixing things for myself, I'd rather help everyone else who is having problems, but who don't even know where to complain. You might like to read about Web accessibility, and contemplate all those barely-computer-literate users who access the web through library terminals. Think outside your own box of experience. -- Quiddity (talk) 05:50, 27 August 2008 (UTC)

Actually, I know several people with significantly impaired vision, and I haven't found any that don't know how to fix this for themselves. The issue here is that we can't predict what size font is going to work for all computers. If we declare that my default typeface (Times 16) is the minimum, then that's going to prove to be disruptively large for other people. This is a user-fixable situation, not a one-size-fits-all situation. And certainly if you have a problem with your computer's default setting, then you should fix your computer's default. WhatamIdoing (talk) 07:33, 27 August 2008 (UTC)

Disagree. Um, some of us have preference for non-essential text to be in a smaller size, in terms of choice. That is an aesthetic preference, not an accessibility issue. And in my browser, at least, if I find the text too small - and sometimes I do! - I utilize the Ctrl-Scrollwheel function (or Ctrl+Plus or Minus), to up the size of all text until I can read the smallest. I can't say I have any accessibility issue with small text. I find it hard to understand how anybody could have an insurmountable accessibility issue here, with dynamic resizing and/or the Magnifier function of Windows. That's my .02, YMMV. LaughingVulcan 00:23, 11 September 2008 (UTC)

I also disagree. I've expounded at the broader forum at MediaWiki talk:Common.css#Font sizes. For the purposes of the discussion here, the gist is that none of the accessibility guidelines seem to recommend minimum or larger font sizes.  —Michael Z. 2008-09-11 04:28 z

Gadget proposal

Can I have some more opinions about adding a gadget to move the section edit links so that they are easier to use with screen readers? Graham87 14:00, 1 June 2008 (UTC)

I've just voted for the bug that fixed this in the software, don't forget to vote also for this one! BTW, also just noticed that there is a specific category for accessibility MediaWiki bugs, which is a good thing (and very encouraging, indeed). It's important to tag new accessibility related bugs with this tag, and add old bugs to this category (if all of us vote for them, they will be fixed in less time). I've just tagged a couple of old bugs. Cheers, —surueña 11:25, 3 June 2008 (UTC)

I read in some bug report that developers ignore votes. I can't remember where I read it, but I've seen many bugs which caused a lot of distress bug 9213 being an example, not being acted on for months. The accessibility keyword gives the bug a high priority, and I think adding that to all accessibility-related bugs is more importannt. Graham87 12:00, 3 June 2008 (UTC)

OK, understood. I searched and tagged more accessibility-related bugs, but there are surely more. Cheers —surueña 13:40, 3 June 2008 (UTC)

Navboxes need more flexibility

As currently written, WP:ACCESS demands that all navigation boxes be placed after the lead and before the table of contents. While I think this is fine for some navboxes, I can't support this approach for all navboxes in all articles, because of the three problems it causes:

• Implying an inappropriate level of importance. {{Cardiac glycosides}}, like hundreds of similar medicine-related navigation boxes is intended as a convenient alternative to manually adding long, identical lists of medication-related articles to See also in dozens of articles such as Digoxin. Putting it at the end of the lead is essentially putting See also at the end of the lead. It's obvious from the visual layout that this template was intended to be placed at the very end of the article: it runs full-width across the screen. Also, can you imagine anyone starting at Digoxin for the purpose of finding Proscillaridin?
• Screwing up the formatting. Look at what happens to the formatting at Phylogenetics if you move {{Evolution3}} after the text of the lead. The navbox runs down into the text of the next section. On older browsers, this could result in covering up text. (And on not-so-old browsers, either: In my entirely up-to-date browser (and given my font settings), the taxobox very slightly displaces an image so that it covers up the first four words at Plumeria#Etymology and common names.)
• Overloading the lead. A huge number of science and medicine articles have large infoboxes (sometimes called taxoboxes) -- particularly if you look at articles on medications or living organisms. Consider what happens when you have both an infobox and a navbox in the lead. Think about what Digoxin would look like if the navboxes were added to the lead. You'd have rather more screens of 'sidebar' navboxes than you would of text.

I think that we need to clarify in this guideline that not all articles should have all navigation boxes at the top. Navboxes in the lead should probably be restricted to shorter navboxes that are believed to be of immediate interest to the general reader, and even then only added to the lead in the absence of a large infobox (i.e., when it won't make subsequent sections illegible).

Furthermore, if the information in the navbox is essentially See also material, then it should be placed at the end of the article. Portals, for example, should probably be placed in the See also section in most articles. After all, if you're already at Plumeria, you probably want to read about these flowers instead of taking an immediate trip to Portal:Plants.

Does anyone object to clarifying these points? WhatamIdoing (talk) 18:54, 24 August 2008 (UTC)

I don't believe this guideline intends to demand that navboxes be placed in the lead, rather to state that when they are placed in the lead, they should follow the text. SandyGeorgia (Talk) 19:14, 24 August 2008 (UTC)

I'm all for clarification. So I don't mind. Butwhatdoiknow (talk) 20:27, 24 August 2008 (UTC)

I agree with SandyGeorgia, it doesn't try to enforce that all navboxes should be placed in the lead, but because the current practice is to put some (vertical) navboxes at the top of the article it is more accessible to move them below the lead than above it. Of course it doesn't suggest that those (horizontal) navboxes usually put at the bottom of the article should be moved to the top (is that your point?). But adding a clarification in the text can avoid any misunderstanding, so feel free to add it to that guideline. With respect screwing up the formatting and overloading the lead, this guideline doesn't create those problems because there are a lot of navboxes so long that will reach the first section even if it is placed above the lead. Maybe that's an issue with the CSS or browsers, I don't know, but IMO we shouldn't discuss that here. BTW, thanks for your interest in improving the guidelines, WhatamIdoing, and for all your updates, Butwhatdoiknow. Cheers, —surueña 20:54, 24 August 2008 (UTC)

I imagine that WP:ACCESS doesn't intend to demand that all navboxes appear in the lead, but it fails to provide for any alternatives. Compliance with this guideline is mandatory at FAC, so we really need it to authorize all of the possibilities (or to explicitly limit itself to the specific instances that it means to control). WhatamIdoing (talk) 22:11, 24 August 2008 (UTC)

I think this is the part that is missed:

• When the optional elements are used they should be in the following order:

It doesn't demand those items be in the lead; it says when they are in the lead, they should be in that order. That doesn't contradict, in my mind, the navbox guideline at WP:LAYOUT (which has navboxes at the end of the article), but I agree that we need more clarity here. SandyGeorgia (Talk) 22:25, 24 August 2008 (UTC)

Yes, a clarification can improve the wording here. Please, note that when I wrote that guideline what I had in mind was articles with up to 1 infobox, and one vertical navbox (both usually at the top) —and zero, one or several horizontal navboxes at the bottom— which was the common practice. But now it is very common to have more than one vertical navbox in an article, so this guideline should also recommend what to do with vertical navboxes placed outside the lead section (as Graham says below, they should be placed at the end of any section, just before another heading to be able to skip the navbox quickly to that heading). —surueña 09:14, 25 August 2008 (UTC)

White space

This is coming up more often now that I'm watching for it at WP:FAC, so I could use more guidance. When an infobox is very very very long, placing a vertical navigational box below the text in the lead results in an extreme amount of white space. So, editors have been placing the navbox under the infobox. This is a no-no per the guideline and for screenreaders. But I can't move it to the end of the text in the lead because it creates massive white space. And I can't move them to the end of the article because they are vertical templates and don't work well at the bottom of the article, where they belong according to WP:LAYOUT. Does ACCESSIBILITY on screen readers have any opinion on placing a vertical templates somewhere in a section in the middle of the article, below the lead? See the issues in my recent edits, trying to fix AMX-30E. I don't know how to solve that navbox, and the article nominator is questioning on my talk page what to do. This is the version before I moved the navbox down. SandyGeorgia (Talk) 21:04, 24 August 2008 (UTC)

The main problem I have with navboxes is moving past them to the rest of the article. I prefer them at the very end of the article for that reason, but before the TOC or at the end of a section is fine, because I can navigate past them by navigating to the next heading. Graham87 00:57, 25 August 2008 (UTC)

Is it just as easy to skip over the infoboxes? Why should an infobox go first, but a "sidebar" navbox be last in the lead? WhatamIdoing (talk) 07:14, 25 August 2008 (UTC)

Well, the idea is that whereas a navbox is a very long collection of links to related articles, and therefore many people are not interested at first in them, in theory an infobox is a brief summary of the article so you are interested in reading it before the lead. But maybe that assumption is wrong. What do you think, Graham? Do you usually read whole infoboxes, or do you skip them often? Can you skip to the lead section easily? In that case, maybe the infobox should be placed below the lead and the vertical navboxes below other sections. Cheers, —surueña 09:14, 25 August 2008 (UTC)

I just experimented with placing an infobox below the lead text, and I don't think that is something that the community would accept. It's unsightly. SandyGeorgia (Talk) 16:13, 25 August 2008 (UTC)

I agree. Infoboxes are very useful, and they should be at the beginning of the article, if not at the top at least just after the lead section. But I prefer to put them at the very top, as done now. —surueña 21:09, 25 August 2008 (UTC)

SandyGeorgia, after seeing your fixes to AMX-30E I understand your point now. It's true, that special kind of navboxes relying in the {{FixBunching}} template are an accessibility problem: they are designed to be placed just below infoboxes, and if you try to move them below the lead section the whole (graphic) layout will be broken (see [1]). I think that your decision of moving that navbox to the bottom of the article was the correct one, but those navboxes are designed to be placed below the infobox so we must find a solution and inform the authors of those infoboxes about the accessibility problems. Anyone with enough CSS knowledge to avoid breaking the layout when placing the infobox above the lead and those navboxes below the lead section? I will ask in Template talk:FixBunching... —surueña 09:59, 25 August 2008 (UTC)

Thanks ! But if I understand correctly, you're saying it's also possible to place a vertical navbox below the text in any other section in the middle of the article? SandyGeorgia (Talk) 16:13, 25 August 2008 (UTC)

Yes, from my POV that's accessible. However, I think that should be avoided for one reason: wikipedians actually don't read the guidelines / policies, they just repeat the conventions seen in other articles. And therefore, the rules must be very, very simple to be able to remember them. Initially it was very common to put the infobox above the dablink to "save space", but thankfully nowadays people have accustomed to put them at the very top (after several months seeing that articles were changed). That rule is easy to remember. We are also changing the images in the middle of articles, so people get used to see them just below headings or inside a section, but never just above a heading (when a level 2 heading is just before a level 3 heading, for example, I always put the image below the level 3 heading even if the image can also logically belong to the level 2 heading, to avoid seeing images just above any heading. See [2]). And it would also be easy to remember to put vertical navboxes just below the lead section, i.e. in front of the table of contents. If we also allow that vertical navboxes can be placed in the middle of articles, I think it would be harder to remember that images should be just below a heading and vertical navboxes just above. IMO that would lead to confusion (i.e. wikipedians would probably think that there is no rule so they put images and navboxes in any position). Maybe this is just non-sense, but I've been working with these rationale (please guys, let me know your opinion about this!). So IMHO I would say: the vertical navbox must be placed just above the TOC (but we must also decide what to do when there are more than one navbox within an article). What do you think? —surueña 21:09, 25 August 2008 (UTC)

Also (more navbox)

The text currently says: "Navigational boxes should be just after the lead section so a Wikipedian using a screen reader can jump to the table of contents without reading the whole navigational text."

What does this mean? "Please put a long list of articles before the table of contents, so we can find the table of contents more easily"? I thought that the entire point was to put the long list of articles before the TOC so that the reader could conveniently skip the rest of the article and go to a more interesting one, without having to skip to See also or end-of-article templates first.

If someone can explain to me the actual goal here, then I'll happily help wordsmith the rule. WhatamIdoing (talk) 22:19, 24 August 2008 (UTC)

I don't know, but it's easy to get to the table of contents because it's a second-level heading. Graham87 00:59, 25 August 2008 (UTC)

Graham, is a navbox at the end of a section in the middle of an article a problem? Some vertical navboxes don't lend themselves well to being placed at the bottom of an article. SandyGeorgia (Talk) 01:26, 25 August 2008 (UTC)

No, it's not. The idea is that an screen reader or a text browser a web page is serialized, so the goal is to be able to read in a logical order the article. Many articles have a dadlink and an illustrative image and caption at the top, for example. If the article has first the image and then the dablink, in a graphic browser it doesn't care much, but a screen reader would read first the image's caption, which is part of the article's contents, and after that will "jump" outside the article to read the dablink (and after that the lead section again). That's illogical, and can be a big problem to wikipedians with learning disabilities (well, that was I think, I haven't performed any experiment). The good organization is to first hear the dablink, then the image caption, and finally the lead (if after hearing the caption or the lead you realize that's not the article you are looking for, you can just jump to the top of the article again and click on the dablink). In the case of a navbox, the idea is that probably you don't want to hear the complete list of related articles, so you can just jump to the next heading (including the table of contents, which have an h2 header). If there is text between the navbox and the next heading (e.g. the whole lead section), you would miss that part of the article. But it doesn't matter if the navbox is just before the TOC or another heading, but the usual practice is to put them at the top of the article. I hope this can clarify the goals :-) Cheers, —surueña 09:32, 25 August 2008 (UTC)

Special cases

Some short articles have a very long vertical navbox, but they have so few sections that they don't even have a TOC. Therefore, the navbox cannot be place below the lead section (see for example [3], and [4]). So either we have to make here an exception, allowing the navbox above the lead section, or either disallow completely the long navbox (just a link to the main article in the see also section). Opinions? —surueña 10:24, 25 August 2008 (UTC)

I personally dislike vertical navboxes (see the next section) and wouldn't mind if they were banished from existence and all navboxes were standardized to horizontal boxes at the bottom of the article. But I have zero expectation that will ever happen, so ... SandyGeorgia (Talk) 16:18, 25 August 2008 (UTC)

I don't dislike them, IMO they are useful and provide uniformity to Wikipedia. Well, I like articles with just one vertical navbox, more than one is somewhat confusing. And I agree that it's very unlikely that people stop using vertical navboxes, even if a policy or guideline mandates that. In any case, we can just try to enforce a correct use from the point of view of accessibility, vertical navboxes aren't inherently inaccessible when correctly used. In this case, I don't really know if we can suggest that stubs shouldn't have those navboxes. —surueña 20:25, 25 August 2008 (UTC)