Wikipedia talk:Manual of Style/Accessibility/Archive 2
 | This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
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)
Wheelchair article
Resolved30-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)
1001 Wikipedian Nights
Resolved30-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)
Thou hypocrite
Resolved30-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)
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)
Merge with technical
Resolved30-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)
- Re: "I recommend a spinoff guideline to address the ultra-intellectual issues of technical writing"... Um, that's what Wikipedia:Make technical articles accessible is. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:30, 31 August 2008 (UTC)
Lowercase article titles and DAB hatnotes
ResolvedThe 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)
- 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)
- 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)
- 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)
- 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)
- It is usually more effective to simply go to a sandbox and test whether x will affect y than start talk page threads about it. If there's a problem revealed by the test, it would then be useful to use the talk page to suggest changes (or just go make them). — SMcCandlish [talk] [cont] ‹(-¿-)› 23:43, 31 August 2008 (UTC)
- I just tested it, and the order has no effect on the performance of the templates. Logically, the DAB tag should go above the lc one, as the lc one operates on/is about this page, while the DAB is a meta-level above that, saying "this may not be your page". — SMcCandlish [talk] [cont] ‹(-¿-)› 23:51, 31 August 2008 (UTC)
Multiple columns in {{reflist}} deemed bad
Resolved- "Howzat for a provocative headline, eh?" — superlusertc
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)
What the...?!
ResolvedAnyone 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)
- Fixed. -- Quiddity (talk) 17:52, 18 May 2008 (UTC)
Form names?
ResolvedI've never heard of a "form name" before, does that mean "button", or is there a longer list of words that shouldn't be used in headings, and if so, why? Quote: one of the form names on the page, like "search" or "go". - Dan Dank55 (send/receive) 20:32, 30 August 2008 (UTC)
- I'm not adept with HTML, but looking at this page's code, fulltext might be another problem. WhatamIdoing (talk) 01:07, 31 August 2008 (UTC)
- What I meant was the title of a field in a form, like the title of an edit box, a button, a check box etc. As I said in my first writings on accessibility in Wikipedia, this is very rare and form names are very bad section titles anyway. In fact, per my testing at User:Graham87/sandbox5, this is no longer a problem, not even in the JAWS version I used in 2006. Therefore I'll remove it. Graham87 08:03, 31 August 2008 (UTC)