Wikipedia talk:Manual of Style/Accessibility

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.AccessibilityWikipedia:WikiProject AccessibilityTemplate:WikiProject AccessibilityAccessibility

Archives

/Archive 1

WCAG Samurai

Hi, I've just noticed that the WCAG Samurai finally released in June a draft of its WCAG 1.0 errata. This errata is not published by the W3C but by a group of accessibility experts, but I think they are sound and a real improvement updating these guidelines to current web technologies. For example, I've just removed the requirement to use an HTML 'summary' attribute to data tables [1] as explained in the errata. It's true that actually nobody uses it (neither me), and it doesn't offer any real accessibility improvement (the same info can be written in the article's text, so it will be available to every reader).

The drafts of the second W3C accessibility guidelines, WCAG 2.0, have been very criticised, so from my point of view we should stick with WCAG 1.0 + Samurai errata. What do you think? Cheers —surueña 13:02, 15 December 2007 (UTC)[reply]

Wheelchair article

30-Jan-2008: One of the problems I have with the article "Wikipedia:Accessibility" is that it hit me like "Here's the wheelchair article but anyway". Perhaps a short paragraph should be added to explain the term "browser" versus "screen reader" and such: it could be linked to the lede section as one sentence linked to a fuller section later in the article. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)[reply]

1001 Wikipedian Nights

30-Jan-2008: Although no one is buying time by making the article a "shaggy dog story" in the sense of 1001 Arabian Nights, the article seems to be a long, rambling laundry list of issues. The article needs a short, succinct intro section to summarize "Ten Things I Hate about You and Your Writing" to, at least, try to focus on ten guidelines a writer should know before losing interest in Wikipedia. (Actually, the Top 7 would be better, but the Top 10 is probably needed to accommodate the current rambling). -Wikid77 (talk) 10:50, 30 January 2008 (UTC)[reply]

Thou hypocrite

30-Jan-2008: The article "Wikipedia:Accessibility" seems to violate so many aspects of accessibility and readability that it hit me like wiki-hypocrisy. If everything in Wikipedia weren't already iffy, I would have recommended pulling this "advice column" until after trying "Physician, heal thyself" to make the article more readable and usable. Within just a few sentences, the article starts talking about "TOC" with no concern to try showing "table of contents (TOC)" to introduce the acronym. Also, there's really no lede section summarizing the issues being presented. OMG, just think: with unknown acronyms and no lede section, just imagine how unreadable the remainder of the article could be. I won't generate a laundry list of complaints: people simply need to realize the article needs to be rewritten, then ask for reviewers. Guidelines need to be written to the highest standards, above just featured-article content. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)[reply]

Skeleton crews

30-Jan-2008: In most areas of Wikipedia, the content is being written and condensed by mere "skeleton crews" of volunteers: even the guidelines are revised by just a relative handful of people. For that reason, the content is often hollow, sparse, and marginal, as compared to writings by full-time staff writers. As a consequence, the Wikipedia policies rarely get the help and reviews that are needed. No one should feel blamed for the lowered content; it is a monumental task even if there were full-time pay. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)[reply]

Merge with technical

30-Jan-2008: Should article "Wikipedia:Make technical articles accessible" be merged with article Wikipedia:Accessibility?

Heck no. Overly technical articles might be only 2% (if that) of the total article base, hence 98% of writing does not need to worry about revising technical articles. I've tried simplifying dozens of those very complex articles (see: Discrete Fourier transform), and I recommend a spinoff guideline to address the ultra-intellectual issues of technical writing. Just try simplifying several of those "too technical" articles ("{{technical}}"), and it becomes clear that there are numerous high-tech issues to address, beyond where to place an infobox. -Wikid77 (talk) 10:50, 30 January 2008 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

lowercase articles

The guidelines specify that disambiguating hatnotes should always go on top. Does this still apply in cases where the article uses the template {{lowercase}}? Or would having something above that template interfere with its function? Just wondering. --ShelfSkewed Talk 17:04, 7 April 2008 (UTC)[reply]

Interesting question, but I'm not sure what do you want to ask. AFAIK, initially this template just reported that the article's title must be in lower case, but due to technical limitations (MediaWiki features) it wasn't possible. Later, it added some JavaScript to "fake" the title (rendered it with lowercase, although MediaWiki really sent the page with the title in uppercase) but if JavaScript was disabled the fallback solution was to still render the old hatnote (so I suppose this is what all screen readers and text-only browsers showed, and thus accessible). But now it seems that MediaWiki implements a new attribute (DISPLAYTITLE) to really generate pages with lowercase titles. So now it doesn't matter when the {{lowercase}} is placed (from the POV of accessibility) because it doesn't generate a hatnote anymore, but IMO when it did that in the past it should be placed below the disambiguation links. Have I answered to your question? HTH —surueña 19:25, 7 April 2008 (UTC)[reply]

I think so, although I wasn't thinking about any hatnote generated by the {{lowercase}} template. The particular article I was looking at was Go! (airline), which the template causes to be rendered as go! airline in the title display. What I was wondering was, if the disambiguation template is placed above the lowercase template, will the latter template still lower-case the display--that is, will it still function as intended? When I moved the disambig template to the top, everything seemed to work fine in the "Preview" view, but in the "Show changes" view, the article title was rendered capitalized. So I moved the dab hatnote back down before I saved, in case it was messing something up. But you are saying that the {{lowercase}} template should function correctly no matter where it appears on the page?--ShelfSkewed Talk 19:47, 7 April 2008 (UTC)[reply]

Never mind: It does the same thing (give different displays in "Show preview" vs. "Show changes" view) even with the lowercase template on top. Poor scientific method on my part; I should have checked both ways when I first noticed the difference. --ShelfSkewed Talk 20:44, 7 April 2008 (UTC)[reply]

OK, understood. But note that I didn't said anything about the correct behaviour of {{lowercase}}, but about that this template doesn't have any accessibility issues with respect its placement at the page (I don't know if it has any restriction to work properly). Cheers, —surueña 23:10, 7 April 2008 (UTC)[reply]

Multiple columns in {{reflist}} deemed bad

"Howzat for a provocative headline, eh?" — superluser_tc

There have been some discussion on Template talk:Reflist about whether to remove multicolumn support from {{reflist}}. The simple solution would be to remove support for it in the reflist template, however, some users suggested it might be better to have a policy change? (I'm guessing they where referring to MoS?). So if you have any thoughts about that please consider taking part in the discussion.
— Apis (talk) 21:41, 15 May 2008 (UTC)[reply]

What the...?!

Anyone else notice that WP:ACCESS (in all uppercase) leads here, but wp:access (in all lowercase) leads to "make technical articles accessible"? Was this intentional, because it's messing me up and I can't be the only one...!? L'Aquatique[talk] 06:15, 18 May 2008 (UTC)[reply]

Fixed. -- Quiddity (talk) 17:52, 18 May 2008 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]