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]