Wikipedia talk:Manual of Style/Accessibility/Archive 12

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 5

←

Archive 10

Collapse and strange multicolumn markup

The page List of Christian media organizations is using {{collapse top}}/{{collapse bottom}} to hide content. Even worse, if you actually expand the first collapsing section, it has these strange table headings which make it very difficult to understand which parts correspond to which headings. When I went to the "printable version" link under the "print/export" tab, I found there was no content at all. The reason being that the collapse templates are hidden in print. Is there a better way to organize this information so that it doesn't need to be entirely collapsed? Suggestions are welcome. Thank you. Frietjes (talk) 22:15, 8 April 2011 (UTC)

Pi vs π

There is a discussion at Talk:Pi on whether to move the article to π. I expressed some concern as to any accessibility problem, but I'd welcome input from people more familiar with the issues.--agr (talk) 21:12, 4 April 2011 (UTC)

Good question. Symbols like π can create acessibility issues, especially with screen readers. However, we cannot know the result in a screen reader without testing each character. Thus, it is best to ask user:Graham87 for input on this issue. Either the symbol will have a textual transcription like "Pi" given by the screen reader JAWS, and then it's OK. Either it will be read as a question mark, and then it would be better to keep the title "Pi".

Aside from the question about accessibility, this decision to rename the title will have a huge (huge) impact on search engines. Users type "Pi" into Google, not "π". Google will ussume the page is about "π" and not "Pi". Thus, the ranking of the page in Google will significantly decrease. Dodoïste (talk) 22:21, 4 April 2011 (UTC)

When I type "π" into google it returns results for both Pi and π, but in the context of the number of Greek symbol. When I type "pi" into google, it also returns results for seattlepi.com (Seattle PI or Seattle P-I). It appears Google understands the ambiguity, but if possible (and not a problem for browsers and screen readers), π is better, since it is more precise in terms of its meaning. Frietjes (talk) 22:39, 4 April 2011 (UTC)

I've commented there. JAWS reads the π symbol as "p". Graham87 00:48, 5 April 2011 (UTC)

OK. Thanks Graham. :-) No problem for screen readers then. Well, other screen readers are not as high-quality as JAWS, and might not be able to read it. But JAWS is the most popular and widely used, and it's the responsibility of other screen readers to match JAWS's quality.

@Frietjes: concerning Google, the issue is far more complicated than what you appear to think. Of course Google will give you results for "π" too. The whole problem is, it won't give you the same results. Dodoïste 83.173.207.141 (talk) 07:23, 5 April 2011 (UTC)

There's a point that might not be quite so obvious to you, Dodoïste. In English, it would not be acceptable to have an article titled "P", when its subject is "Pi" - they sound so different that it would cause confusion. I think that in French they may sound rather more alike, and it might be more acceptable. I really couldn't support that proposed change of title because of its impact on the visually impaired. --RexxS (talk) 13:59, 5 April 2011 (UTC)

Heh, thanks for the clarification. I had a feeling I made a mistake when I saw Graham87 voted "oppose". I thought the pronunciation of "p" was similar to "Pi" in English. In French, "p" and "Pi" sound really different, so my mistakes does not come from that. I still have a lot to learn about English pronunciation, obviously. :p OK, then I oppose the change of title too. Dodoïste (talk) 15:57, 5 April 2011 (UTC)

Just for your information, English-language pronunciation of the Greek letter "Pi" is usually the same as that of "pie" (the pastry), while the pronunciation of the English letter "P" is usually the same as that of "pea" (the vegetable), giving rise to various puns. [I don't recall seeing references to Pea Pie, but if it existed, it would sound like the pronunciation of "P π".] When I learned the French alphabet, I think that "P" sounded like "pé" in French or roughly like "pay" in English. I haven't learned to pronounce the Greek alphabet in French, but I would guess that "Pi" would sound roughly like the English "pea". [So a French pronunciation of "P π" would sound very roughly like the English pronunciation of "Pay Pea".] Oddly enough, my 2004 Petit Larousse Illustré offers no French pronunciation for either "Pi" or "P".
¶ [Also for the curious, The Seattle Post-Intelligencer, which ceased its printed edition a few years ago, was and is often referred to locally as the "P-I". Since Google searches, like many items on Wikipedia and Sporcle, routinely discard punctuation and capitalization, it's not completely surprising that the results for "Pi" or "pi" would reflect the results of frequent queries for the "P-I"; I'm sure that lower pages would show search results for "P.I." as "Private Investigator" (as in Magnum, P.I.) or "Philippine Islands" (as in Manila, P.I.)] —— Shakescene (talk) 00:53, 11 April 2011 (UTC)

Thanks for the clarification. Yes, your memories of French pronunciation are accurate. :-) Dodoïste (talk) 16:59, 11 April 2011 (UTC)

Navbox coloring

I would appreciate any comments at Template talk:Omaha#Orange. Thank you. Plastikspork _―Œ^(talk) 19:14, 10 April 2011 (UTC)

Same ol' I'm afraid. It's a symptom of the failure to understand that just because you can have 2^24 different colours, you don't have to use them all (particularly on the same page). --RexxS (talk) 02:43, 11 April 2011 (UTC)

Not quite as bad, but see Template talk:Hamilton, Ontario. Frietjes (talk) 15:14, 12 April 2011 (UTC)

You would have to wonder what was the point of writing WP:Deviations to explain the benefits of site-wide styling. --RexxS (talk) 22:48, 12 April 2011 (UTC)

And even if you point someone to it, they still revert your edits. Frietjes (talk) 16:05, 15 April 2011 (UTC)

It continues at Template talk:Hamilton, Ontario. Frietjes (talk) 15:57, 18 April 2011 (UTC)

Horizontal lists in navboxes

Many thousands of Wikipedia articles have navboxes, in which lists of links are presented, horizontally, without using list mark-up, but instead using {{·}} or suchlike as a kludge. This is semantically poor and has implications for accessibility.

I created {{Flatlist}} in an attempt to begin addressing this, but previous discussion (two-and-a-half years ago) petered out before various concerns were resolved. Now that CSS an browsers have moved on, I'd like us to find a solution. Ideas? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:58, 28 March 2011 (UTC)

The main sticking point from a very brief skim of that discussion seemed to be the cludge of using the CSS border attribute to fake a separator. Surely most modern browsers have sufficient support of the list styles parameters to afford us the ability to use the same small bullet as presently created by {{,}} if we want? Assuming that's the case, and also assuming that we've standardised sufficiently on {{,}} as a separator in navboxes, it should be easy enough to hack up a sandbox copy of {{navbox}} and {{,}} which retains perfect backwards compatibility. The question is whether {{,}} is used outside of navboxes, which would complicate things. Chris Cunningham (user:thumperward: not at work) - talk 15:24, 28 March 2011 (UTC)

Discussion of CSS borders was a red herring; I proposed the use of alternatives more than once on the earlier discussion; and yes, the proper solution will be to use <li> elements, and then style the bullets, such that they degrade gracefully to regular round bullets, in older browsers or where CSS is disregarded. The trick will be to apply a different style ("first-child" to the first bullet in each list. We should be able to do all that without modifying {{,}}. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:26, 28 March 2011 (UTC)

Not as straightforward as it ought to be. Once you set display:inline, you can't use list-style- as that requires display:list-item. The usual solution is to make the bullet-point into a background image and apply it to the second and subsequent li tags, which ought to look something like this:

<ul>

...

</ul>

except of course, I don't know how to refer to an image by url when using the wikimedia software – I think it's disabled. If you can do that, then it's solved.

The selector 'li:before' might offer an alternative, but doesn't work with IE up to 8. Generally, the most accessible way of rendering decorative visual elements should be by styling them as background images, so I'd favour that solution. Is there a way of specifying an image of a middot in the way that want, or do we have to ask developers for an implementation? --RexxS (talk) 18:14, 28 March 2011 (UTC)

There was discussion above at #Template:Flatlist indicating that the problem identified a couple of years ago about non vertical bars has still not been addressed and that the {{Flatlist}} template needs changing before being widely used. This problem has still not been addressed and needs to be addressed. Keith D (talk) 20:26, 28 March 2011 (UTC)

Yeah, I agree. I came to this project completely unaware of its requirements and expectations. I saw this template was "recommended" yet used fewer than 100 times across all of Wikipedia. It needs to be worked on before we can use it appealingly to both ACCESS and non-ACCESS readers. (For a parallel on ACCESS-based take-up, the {{dagger}} template was created not more than a few months ago but is already used as a de facto standard template on lists, perhaps well over a hundred times....) The Rambling Man (talk) 20:32, 28 March 2011 (UTC)

Is the dagger in use on semantically marked-up lists? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:30, 28 March 2011 (UTC)

{{dagger}} is now used throughout dozens of lists for access purposes. The Rambling Man (talk) 21:47, 28 March 2011 (UTC)

Thank you, but that's not what I asked. I asked about its use in semantically marked-up lists. Perhaps you could provide an example? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:53, 28 March 2011 (UTC)

No, thank you. As I said before, I came here completely unaware of the project expectations and requirements. Perhaps you could explain what you mean in accessible (to me) terms (and forgive my ignorance with respect to your question...). Either way, {{flatlist}} (as I asked about some months ago) is virtually unused and I questioned its recommendation then, as I do now. The Rambling Man (talk) 21:57, 28 March 2011 (UTC)

This section is about replacing paragraphs of text, in which words or phrases are separated by bullet characters which are rendered as part of the content (for example when it is spoken to assistive technology users; e.g. "one dot two dot three dot..."), with proper HTML lists, using <li> elements, in which the bullets (or whatever visual indicator is used) are not rendered as part of the content, and so are not read out (e.g. "one two three..."). The latter is more accessible; and has other advantages, too. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:10, 28 March 2011 (UTC)

I think I get it. Since {{flatlist}} is virtually unused across Wikipedia, perhaps it needs updating to be useful to everyone? If you can make it useable and appealing to visual readers then there should be no problem. The Rambling Man (talk) 22:13, 28 March 2011 (UTC)

That - visual appeal; it's already perfectly usable - is what I'm asking people to help me do. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:34, 28 March 2011 (UTC)

There is no "problem identified a couple of years ago about non vertical bars"; because there are no "non vertical bars". This was explained to you in the earlier (2008) discussion. Note also my above comment: "Discussion of CSS borders was a red herring; I proposed the use of alternatives more than once on the earlier discussion". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:30, 28 March 2011 (UTC)

It "looks like" vertical bars on screen, that is the problem. If you do not want to call it vertical bars then that is up to you but the problem remains and needs to be addressed. Keith D (talk) 22:14, 28 March 2011 (UTC)

I'm very glad that you accept that they are vertical bars. No problem with them has been evidenced. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:34, 28 March 2011 (UTC)

I am not saying there is no problem I can see the problem with them. Rather than argue about whether they are vertical bars or not, why not fix the template to be acceptable and then it can be used. In the last two and a half years there has been no change in the template to address the problem and you just keep coming back pushing the template. Keith D (talk) 00:14, 29 March 2011 (UTC)

Now you're simply making things up. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:17, 29 March 2011 (UTC)

I think that's what I'm trying to say as well when I say "If you can make it useable and appealing to visual readers then there should be no problem". The Rambling Man (talk) 22:16, 28 March 2011 (UTC)

Basically, TRM, I think we want something that looks like this, which works in all modern browsers and is accessible. But the wikimedia software puts a few barriers in the way of doing it how we should. If we could all agree on what we want from a horizontal list, then we could focus on overcoming the restrictions. --RexxS (talk) 22:58, 28 March 2011 (UTC)

That look fine with the bulleted separators. Keith D (talk) 00:17, 29 March 2011 (UTC)

Doesn't work in ELinks or Lynx, rendering as a standard vertical list. I'm not sure about other text-based browsers. Plastikspork _―Œ^(talk) 01:41, 29 March 2011 (UTC)

I thought it degraded rather gracefully in Lynx. As a text-only browser won't display the background image that the CSS supplies, I think I'd prefer to see it in vertical format, rather than horizontally without any separators. YMMV, --RexxS (talk) 12:27, 29 March 2011 (UTC)

Question Are we going down the road of Accessibility at the sake of the Wikipedia policy of keeping markup simple, which I have not scene brought up here at all. I think we need to deal with this matter with the most minimal markup we can while allowing for accessibility.SaysWhoWhatWhenWhereWhyHow? (talk) 02:29, 29 March 2011 (UTC)

I think the key to solutions like this, is that almost all of it would go in Mediawiki:Common.css. Plastikspork _―Œ^(talk) 03:03, 29 March 2011 (UTC)
- I just hope that we make it simplistic, so that it is not burdensome to implement. You could develop a template to make it, so all we have to do is {{______}} and that would take care of it like Dagger.SaysWhoWhatWhenWhereWhyHow? (talk) 03:44, 29 March 2011 (UTC)
  - I am sure that the end result will be that the editor types something like {{HL | Item 1 | Long Item 2 | Im 3 | Item 4 }}.
  - @PS, It would be nice to think that common.css would accommodate the classes we want, but if need be, we could use inline styles in the template page. The only loss of functionality would be the inability for editors to have their own markup override the common skin for horizontal lists. --RexxS (talk) 12:27, 29 March 2011 (UTC)

Note that some navboxes (for example, chronologies, {{Courtesy earls}}) contain ordered lists. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:52, 29 March 2011 (UTC)

CSS version 1 (obsolete)

Try putting the following into your monobook.css or vector.css:

Extended content

:[Note: Obsolete CSS collapsed. See improved version, below. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:44, 31 March 2011 (UTC) ]

/* Style for horizontal lists */
.hlist ul, .hlist ol {
    padding: 0em;
    margin: 0em;
}
.hlist li { 
    padding: 0em 0.1em 0em 0.9em;
    display: inline;
    background-image:url(http://up.wiki.x.io/wikipedia/commons/d/da/Middot.png);
    background-position:left center;
    background-repeat:no-repeat;
}
.hlist li:first-child {
    padding-left: 0em;
    background: none;
}

and look at User:RexxS/Hul. It needs testing in browsers, but it may be a possible solution. Note: trying to use inline styles fails, so I believe that the only solution would be via MediaWiki:Common.css. If this styling is possible, then the options are:

to make a modification to {{Flatlist}} and keep the "horizontal" class;
to make two more similar templates to complement Flatlist/Endflatlist with a new class;
to make a single template that could take up to N items (20? 30?) in the form {{HUL | Item 1 | Long Item 2 | Im 3 | Item 4 }} with a new class.

Thoughts? --RexxS (talk) 02:46, 30 March 2011 (UTC)

Thank you. that works well (in FF4 under windows), with one exception. When there are several lines of items, there are "bullets" at the start of some lines (every line after the first, in some cases). It might be better to move them after each item (and thus omit them from the last-child, rather than the first). I note that you have applied the class to a wrapping DIV, rather than the UL element. What's the reason for that? On your latter point, I would like to see {{Flatlist}} modified, even if we also take your third option ; the CSS borders were only ever intended as a stop-gap. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:31, 30 March 2011 (UTC)

CSS version 2

Yes, I think there will always be a problem of some sorts when the horizontal list wraps. I'd agree that it would probably be visually preferable to have lines ending with a separator than to have lines beginning with a separator, and your improvement would only need minor modifications to the CSS, I think:

[put the following into your monobook.css or vector.css]

/* Style for horizontal lists (separator following item) */
.hlist ul, .hlist ol {
    padding: 0em;
    margin: 0em;
}
.hlist li { 
    padding: 0em 0.9em 0em 0.1em;
    display: inline;
    background-image:url(http://up.wiki.x.io/wikipedia/commons/d/da/Middot.png);
    background-position:right center;
    background-repeat:no-repeat;
}
.hlist li:last-child {
    padding-right: 0em;
    background: none;
}

Please feel free to modify that if I've got it wrong. I applied to a wrapping div, mainly to maximise its compatibility with {{Flatlist}}, in case we wanted to implement by simply modifying the 'horizontal' class in common.css. It has the advantage that I think it can be applied to a div containing lists using wiki-markup (* #) – as we can't directly apply the class to the ul/ol element in those cases. Cheers, --RexxS (talk) 14:09, 30 March 2011 (UTC)

That's good; and your rationale makes sense. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:09, 30 March 2011 (UTC)

I followed the discussion, though I did not have much time to participate. I've just tested RexxS proposal, and it looks great in FF4 on windows. You're doing a really good job here, ReexS. Keep it up! :-) Dodoïste (talk) 18:50, 30 March 2011 (UTC)

~~May be I am doing something wrong but it does not appear to work in Firefox 3.6 and causes problems with other scripts not loading.~~ I worked out what I was doing wrong. It works OK for me now in Firefox 3.6. Keith D (talk) 21:54, 30 March 2011 (UTC)

I made test-cases of large and complex navboxes (before-and-after) at User:Pigsonthewing/scratchpad_2. What's the best place to ask for people with older/ esoteric browsers to test it? the only issue I can currently see is that the new bullet is a little bigger than the old one. That doesn't bother me, but no doubt somebody will complain. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:36, 31 March 2011 (UTC)

I've uploaded a smaller version of File:middot.png to match the 2px by 2px size of the dot employed in {{Bach cantatas}}. The item spacing is different now of course. The original was mimicking the spacing in {{Flatlist}}; but with the smaller dot, I think it could be closed to approximately match {{Bach cantatas}} by changing the padding in ".hlist li" to padding: 0em 0.54em 0em 0em; (0.55em is too big using FF4!), which is quite compact. There are very, very slight differences in rendering with different browsers, but so far I've tested in Windows: FF4, Opera11.01, Chrome10.0.648.204, IE8.0.6001. It renders cleanly as a vertical list with '*' as the bullet in Lynx. Tomorrow, I'll find an old Win2000 pc out and see what kind of mess IE6 makes, and I'll check the browsers on a linux pc. We could do with someone to test it on Safari and IE7, but that should cover about 95% of our viewers. It would be worth asking User:Graham87 to tell us how it sounds on JAWS. Cheers, --RexxS (talk) 00:15, 1 April 2011 (UTC)

It reads like a normal vertical list, as it should do, in JAWS. I don't anticipate any problems with other screen readers. Graham87 03:36, 2 April 2011 (UTC)

Indeed. This proposal follows strictly the W3C standards, we're doing absolutely what we're supposed to. Thus, there is no risk from an accessibility nor browser specific rendering point if view. The most sensible content of the CSS used here is "last-child", and it is supported by IE since IE5. No worries. Yours, Dodoïste (talk) 09:20, 2 April 2011 (UTC)

Thank you, Graham. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:22, 2 April 2011 (UTC)

I've added {{Courtesy earls}}, which used an ordered list, to the test page. It seems to work well. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:22, 2 April 2011 (UTC)

Moving forward

What next? Have we done sufficient testing? How do we proceed? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:51, 7 April 2011 (UTC)

(Quickly as I have little time) We've made enough testing. Now we should suggest to implement this new CSS at Mediawiki talk:common.css. Yours, Dodoïste (talk) 22:09, 7 April 2011 (UTC)

Discussion initiated at MediaWiki talk:Common.css#Horizontal lists. I hope Andy doesn't mind me quoting his introduction from this page, as I thought it encapsulated the need for horizontal lists better than anything else I've seen. --RexxS (talk) 02:02, 8 April 2011 (UTC)

Not at all; and thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:40, 11 April 2011 (UTC)

The class "hlist" has now been implemented in common.css, so is available throughout. Anybody who changed their personal css can remove the hlist definition now. The only outstanding question (posed at MediaWiki talk:Common.css#What about .horizontal? is whether or not to deprecate the "horizontal" class. --RexxS (talk) 10:55, 20 April 2011 (UTC)

Navboxes

Thank you, everyone, for making this happen. It's a big step forward in making Wikipedia's HTML both more accessible and more semantically meaningful.

Or it will be, when we apply the class to Navbox templates ;-)

How can we do that? We need to apply the class (in {{Navbox}}, or in a sub-template like {{Flatlist}}, and we need to change the markup in navboxes (make lists, remove bullet separators - a bot job?). Should we move the discussion to Template talk:Navbox? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:41, 20 April 2011 (UTC)

Or, rather, Template talk:Navbox. Graham87 14:28, 20 April 2011 (UTC)

I've tried the class out (directly) on Template:Decompression by inserting div class="hlist nomargin" wrappers and manually replacing the middot templates with wikilist *'s. It's very repetitive and well suited to being done by a bot. However, there's an argument that it would be better to modify {{Flatlist}} to use div class="hlist" or div class="hlist nomargin" (maybe we need 2 versions? or a parameter that decides whether bottom-margin is 0 or inherited?). Then we could use Flatlist to implement the new class in other templates such as those using Navbox. --RexxS (talk) 17:32, 20 April 2011 (UTC)

Thank you. Fixed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:14, 21 April 2011 (UTC)

I've started discussion on applying this to navboxes. Contributions welcome. See also two related deletion debates; ditto. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:12, 22 April 2011 (UTC)

Color of wrestling templates

A bit of an edit war has now spawned some discussion at Wikipedia talk:WikiProject Professional wrestling. All input is welcome. Thanks! Plastikspork _―Œ^(talk) 03:05, 25 April 2011 (UTC)

The color of meat

Comments at Template talk:Meat are most welcome. Frietjes (talk) 16:26, 15 April 2011 (UTC)

Seems like you fixed the issue yourselves. :-) Dodoïste (talk) 21:49, 1 May 2011 (UTC)

Bot to fix headings

A request has been made for a bot to fix improperly nested headings in articles, to improve screen reader accessibility. If interested, feel free to review the bot request. —SW— ^chatter 23:28, 20 April 2011 (UTC)

The bot request is all fine, well done. ;-) I read it completely several days ago, but forgot to comment here, sorry. Cheers, Dodoïste (talk) 22:05, 1 May 2011 (UTC)

About Image Mapping and Captions

Should images that have image mapping have a caption that identifies each object in the image? I'm pretty sure there are some web browser devices that can't read image mapping, so the caption might be a good idea. However, I just want to make sure that follows the guidelines of MOS Accessibility. The image is the first one at List of tallest buildings in Austin. It already has image mapping, and Matthewedwards Chat says I should add a caption listing the different buildings, in case devices cannot read the image mapping. — Preceding unsigned comment added by TheAustinMan (talk • contribs) 14:53, 24 April 2011 )UTC)

If you want to make your article accessible, then as a first step you should see what happens when you try to navigate without using a mouse. The Tab key will move you from one link to another; the Enter key will follow a link; the Backspace key will return you to the previous page. Using the Tab key, I don't get the tooltip identifying the buildings, but I do get links to non-existent articles like AMLI on 2nd and W Austin Hotel & Residences. If I wanted to make sure that I was maximising the accessibility of the image map, I'd make sure it had alt text and then provide a description in the caption of each of the buildings (like you did Wikipedia:Featured list candidates/List of tallest buildings in Austin/archive1), although some editors may think of that as excessive. The question you have to ask yourself is "Do I want to make the article as accessible as I can? or do I want to do just enough to pass FLC?" --RexxS (talk) 15:40, 24 April 2011 (UTC)

The AMLI building doesn't have an article, the W Austin Hotel was a type in the link. Unfortunately with image mapping, you have to link to a page, whether it exists or not. And since Redlinks are okay, I assume this is, too. The images still need better alt text, but I don't think using what User:TheAustinMan said at the FLC is is quite right either, it's just too long, no? Matthewedwards : Chat 05:04, 25 April 2011 (UTC)

You miss the point. The purpose of a client-side image map is to provide links. If there are no articles to link to, then the image map links shouldn't be there. We allow red-links because it encourages editors to create the missing articles when they see the red-links, but there's nothing to indicate in an image map that the article does not exist until you follow the link, which is bad practice. The mistake is to use an image map simply to make use of some browsers' ability to display a tooltip - it's just not accessible to many.

I was not suggesting using the description at the FLC as alt text but as a caption, since it is not obvious from the picture which building is which to anybody unfamiliar with Austin. If you're going to take the trouble to identify the buildings, then you really need to do that for every viewer, not just the ones who use similar browser set-ups to you – that's what accessibility is about. You may think the description is too long; I think there are seven buildings that need a description, and you can only condense that so much. --RexxS (talk) 12:16, 25 April 2011 (UTC)

I think you're asking too much, RexxS. The imagemaps at List of tallest buildings in Austin follow the guidance at Wikipedia:Alternative text for images#Unusual examples, and this requirement should be enough accessibility-wise. There is no need to describe every building, because it wouldn't be very useful informations for most blind users. If they want a description of the buildings or more information, they can follow the link to that page. Why would it be more complicated?

Now I don't like the look and usability of these imagemaps. But that's the developer's problem, not ours. Cheers, Dodoïste (talk) 12:48, 25 April 2011 (UTC)

@Dodoïste: You haven't realised that most of the articles linked to don't exist. How is anyone to obtain "a description of the buildings or more information" from a non-existent page? I'm also concerned that in an article about "tallest buildings in Austin", the lead image doesn't identify those buildings for anyone who isn't using a browser that displays tooltips. I'm sorry to say that Wikipedia:Alternative text for images#Unusual examples does not satisfy WCAG H24, and surely H24 should apply to Wikipedia? --RexxS (talk) 13:12, 25 April 2011 (UTC)

Of course H24 should apply to Wikipedia. But the main requirements of H24 are satisfied in this example, except a few that can be easily fixed by developers.

The requirements are: "To ensure the alt attribute text is visible on mouse-over, the same text should be used on the title attribute. [...] Ensuring the area element alt attribute value is displayed in response to attaining focus (including keyboard focus), and that this applies both to situations where images are loaded and not loaded." This is done, except for the keyboard focus.

See the HTML code produced by MediaWiki:

<area href="/wiki/Spring_(building)" shape="poly" coords="33,122,34,120,32,119, [...]" alt="Spring" title="Spring" />

Seems fairly valid to me. There are a few other mistakes, like the alt text of the image that is missing in the HTML code. And the image should be at the top of the imagemaps, not at the bottom. But these are all MediaWiki developers issues. The code produced by editors in List of tallest buildings in Austin can be successfully used by MediaWiki to produce accessible image maps, so we shouldn't make it harder for editors. Rather, we should fill a bug to the developers, and wait for them to fix it. Cheers, Dodoïste (talk) 14:47, 25 April 2011 (UTC)

In the first image, two articles don't exist out of eight linked. In the second image, five don't exist out of the fifteen linked and an additional one leads to a dab page that doesn't mention the Austin building (the two in the first image also appear in the second). I'm not a member of the Skyscraper Wikiproject and I don't know if articles could or should be created. I'm not really sure how I to try it for myself, and don't worry about the bluntness; I'm open to finding out about this. I didn't know what H24 is, I said when I did the mapping that the article's editors should check in with the people here about accessibility. Would alt text similar to that in the 1896 Democratic campaign poster at WP:ALT#Unusual examples be a good idea, providing it works with mapping (or in place of mapping?) Matthewedwards : Chat 15:47, 25 April 2011 (UTC)

I apologise Matthewedwards, I guess this discussion is getting complicated and confusing. We're currently discussing our accessibility guideline. RexxS might want to change the guideline, or make the guideline aim at higher accessibility - which needs to be discussed. In the meantime, List of tallest buildings in Austin conforms to WP:ALT#Unusual examples, so your job as an editor is done. Just follow the current approved guideline "WP:ALT#Unusual examples", or else we will have various methods to produce accessible image maps at the same time - that would be messy. Cheers, Dodoïste (talk) 16:24, 25 April 2011 (UTC)

Yes, my apologies too. We're having a minor disagreement about how well (or badly) the media-wiki interface produces HTML that satisfies certain accessibility guidelines. Dodoïste's view is that you've done all you can by providing the alt text – and that's certainly a valid stance. I would prefer to encourage editors to provide further description (e.g. in the image caption) because some people not using a mouse can't access the alt text. I agree that the article meets our current standard of MOS:ACCESS, but I will always encourage editors to go beyond that where possible, since featured content represents our very best work.

Matthew: just follow this link to List of tallest buildings in Austin and then press the [Tab] key - you should be able to see what link has the 'focus' (it depends on whether you have an [edit] link enabled for the lead). Press [Tab] again - you should see one of the areas on the image map has the focus (surrounded by dotted lines normally). Press [Enter] - it will take you to a page (i.e. follows a link). Press [Backspace] - it will take you back to List of tallest buildings in Austin with the focus still at the place you left it. Press [Tab] again, and so on. That's how some people have to navigate our articles. You'll see that the tooltips identifying the buildings don't show up for them. It's even worse if you have a low bandwidth connection and have turned images off by default, because you get no idea of whether it's worth loading the lead images (none of the area alt text shows up at all). Hope you see what I mean now. Cheers, --RexxS (talk) 18:37, 25 April 2011 (UTC)

Your stance is valid too, RexxS. However, I'm not sure it will pay off on the long run. For example, if we were to ask editors to make detailed image map captions to compensate a software issue, will we have to remove them when the software issue will be fixed? We both know that editors habits are long and tedious to change. I have concerns that such variations in the guidelines may cause confusion and distrust. Same goes for encouraging higher standards for featured articles: the goal is noble, but the methodology seems unclear. If we had an accessibility guideline clearly dedicated to featured articles, that would make it acceptable.

I'm aware that my stance has its flaws too, as the issue with keyboard navigation you raised isn't likely to get fixed in MediaWiki any time soon. However, I believe we should only advocate long term robust changes. Cheers, Dodoïste (talk) 22:43, 25 April 2011 (UTC)

Signature color for Vermont

See Template talk:Vermont#Green. All input is welcome. Thanks! Plastikspork _―Œ^(talk) 21:08, 1 May 2011 (UTC)

You already said almost everything. Thus, I supported your statement. Cheers, Dodoïste (talk) 22:03, 1 May 2011 (UTC)

Alt text for "gallery" is coming!

Barrel of beer — There's enough beer for everyone, please drink to your heart's content.

See Wikipedia talk:Alternative text for images#Alt text for galleries. Let's throw a party! Dodoïste (talk) 08:00, 3 May 2011 (UTC)

Update of the "Color" guidelines

Diannaa and me have updated the color guidelines. This was on my to-do list for a long time, and I eventually forgot to do it. Thanks Diannaa for reminding me.

Most of the tools to check accessibility listed here were based on the WCAG 1.0 algorithm, which was quite hard to conform to. WCAG 2.0 algorithm for colors lowers the demand. I added informations on how to use these tools, how to ensure that tools not on the list are up-to-date.

Our objective is to be AA level compliant, which is the goal for most web projects. One can't be 100% accessible, we are aiming at what is feasible. In this approach, AA level is already a quite high level. At least, that's the standard approach, I know RexxS and myself often disagree on this point. When you can be AAA level compliant (the highest level), please go ahead. But know that it is significantly harder, and frequently impossible.

If there are any questions or objections concerning this update, I'd be glad to hear them. Cheers, Dodoïste (talk) 15:32, 3 May 2011 (UTC)

Huh, I'm terribly confused about the correct wording "graphic charter"/"graphical chart". What I mean is closer to "style guidelines", or Human interface guidelines. If I understand correctly, a "graphic chart" is a sort of table with graphic data. And, according to this definition, "A graphic charter is the comprehensive document that lists the presentation rules for the graphic elements that convey a website's visual identity." So my understanding of the definition seems correct. However, I probably used these words in a way that led you to think I meant "graphical chart".

Either way, I don't believe it's that important, because in both cases the statement is correct. This color picker can help making graphical charts and graphic charters. And since most editors won't make a graphical charter, it makes more sense to provide advice about graphical charts. Cheers, Dodoïste (talk) 13:03, 4 May 2011 (UTC)

Sounds good ... I'd never heard of a graphic charter until today, so I thought it was simply an error. Graham87 14:15, 4 May 2011 (UTC)

It's a literal translation of "charte graphique" ("style guidelines" is what we would normally use). See http://forum.wordreference.com/showthread.php?t=37458 for a fuller discussion. --RexxS (talk) 00:58, 5 May 2011 (UTC)

Oh, thanks RexxS. Does style guide have the same meaning too? Cheers, Dodoïste (talk) 09:51, 5 May 2011 (UTC)

There's only a tiny difference in nuance, and I suspect that "style guide" is probably an even closer translation. Thanks, --RexxS (talk) 06:49, 6 May 2011 (UTC)

Thanks. :-) Dodoïste (talk) 08:30, 6 May 2011 (UTC)

The color of New Mexico

Any and all comments are welcome at Template talk:New_Mexico#Tan. Thanks! Plastikspork _―Œ^(talk) 03:15, 8 May 2011 (UTC)

It's quite useful to gather feedback before doing major changes. It's good to encourage changes in a few navboxes, to see how editors react. But at some point, we will have to do things on a larger scale. We can't possibly discuss this change at every navbox. I suggest we define a clear style guide for navboxes, and make a request for comment or something in order to gather approval for it. And then, I suppose editors will change all the navboxes themselves. How does it sounds to you? Cheers, Dodoïste (talk) 09:36, 8 May 2011 (UTC)

Sure, having a more targeted style guide would be useful as well. Thus far I have been basically quoting WP:Deviations. However, it frequently doesn't help (see Template talk:Pittsburgh‎). It seems the base desire of many editors is to use "every crayon in the box" and excessively "brand" things with the color scheme associated with whatever sports team, flag, shield, or whatever associated with the region. Sometimes it's helpful to have more than one editor restating what is in the guidelines. Thanks! Plastikspork _―Œ^(talk) 02:50, 11 May 2011 (UTC)

Heading issue in 'Documentation' template

There's an outstanding accessibity issue with header levels in {{Documentation}}; see Template talk:Documentation/Archive 4#Heading fix which still needs attention. Earlier discussion, with one dissenting voice, is at Template talk:Documentation/Archive 2#Heading fix.Could we get some extra eyeballs on that, please, and comments in the new section at Template talk:Documentation#Heading fix redux? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:22, 16 May 2011 (UTC)

Extra Space At The Bottom, Could Be A Bug

I'm not sure why only this page has it, but usually categories don't make an extra space between the bottom of the text and the first category. If it is a bug, it needs to be reported to bugzilla. I am able to do, but you'll have contact me.Curb Chain (talk) 07:50, 25 May 2011 (UTC)

Screen reader interpretation

When I see a sentence that says something like "This takes 12–24 hours", I read it (correctly) as "This takes twelve to twenty-four hours." Do screen readers correctly interpret that, or do they instead read "This takes twelve twenty-four hours"? If the dash is silently dropped, then it might be preferable to spell out the word "to" in our articles. WhatamIdoing (talk) 22:33, 26 May 2011 (UTC)

The dash is silently dropped, but dashes and hyphens are very common in the wider world so screen reader users should know how to process them. Graham87 01:57, 27 May 2011 (UTC)

Help

Can someone please comment at Template talk:Archaeological NRHP in Hamilton County, Ohio. Thank you. Frietjes (talk) 15:26, 27 May 2011 (UTC)

Task force

Can we create some sort of task force to reduce the gratitous color deviations in navigation boxes, infoboxes, etc. ? I am visually impaired, and I am continuously running into conflict when I try to remove such coloring to improve the contrast. For example, only one of the templates in Category:Botany templates deviates (template:botany), but yet check the edit history for that template. I would start an RFC, but it seems as though wp:deviations is very clear on this issue. Perhaps we could discuss strengthening the language? I have no idea what to do about it. It is seriously impairing my ability to use this site. Frietjes (talk) 23:29, 16 June 2011 (UTC)

Sure. For now, I've just reverted to your version, with a few explanations in the diff. Not sure it's going to last, but I don't have time to do much more.

I completely support your initiative and you RFC. You can quote me if you like. And I'm sure the entire accessibility project is with you.

wp:deviations isn't clear indeed, but it doesn't matter because it's not the correct reference. The correct reference is Wikipedia:Manual_of_Style_(accessibility)#Color. Basically, bad color contrast produces content that you can't read. It produces content that visually impaired users cannot read.

As a visually impaired user, you're the perfect person to launch a RFC on the matter. We've been trying to enforce such accessibility improvements for a long time. But people don't see the need to do as we say, because they've never seen a user having such a problem.

For example, since the blind user Graham87 began to participate in improving accessibility, he have been much more listened to than everyone of us. He managed to move mountains, because he was a concrete example for the need of accessibility. You can do just the same, I'm most certain of it.

Please notify me of your replies by e-mail, as I don't have the time to keep up with discussions here anymore. Cheers, Dodoïste (talk) 13:10, 25 June 2011 (UTC)

I would fully support an RFC.

Although I'd advise you to make clear that the RFC is solely for setting minimum standards of colour contrast, with no opinion for or against wider colour usage. Few people could reasonably object to that, but there are those that would see it as an opportunity to attempt to force through more divisive ideas, such as a ban on non-standard colours in navboxes. It's very important that we don't allow these people to derail what should be a civil and pragmatic discusssion. —W F C— 15:17, 25 June 2011 (UTC)

I completely agree with WFCforLife. That's exactly the reason why I said the issue is with the color contrast, and not "wp:deviations". Yours, Dodoïste (talk) 19:08, 25 June 2011 (UTC)

It sounds as though this is a software development issue. Users should be able to set a "Preferences" option to deactivate color settings in navigation boxes. That way, users who can see colors can make use of the coded navigational aids, but users who cannot can select to deactivate the colors. --EncycloPetey (talk) 20:24, 25 June 2011 (UTC)

This is very easy to do if use use "css classes" rather than "inline style statements", as is discussed in WP:Deviations. Basically, if all the coloring is in MediaWiki:Common.css or other style sheets, then a user can create his/her own Special:MyPage/skin.css which has a personal stylesheet. I am fairly certain that Frietjes has done this, checking User:Frietjes/vector.css, which has higher contrast backgrounds for navboxes. The problem is that when you override these classes, it makes it much much more difficult for an individual to choose his/her own theme. In other words, if you were to add a "Botany" class to MediaWiki:Common.css, then all the botany templates could use this class. The colours would stay in sync, and visually impaired users could override these using personal style sheets. However, if there is no strong reason for the particular color choice other than "I like it", then I believe we should just go with the defaults. This is especially important when there are contrast issues, like "dark blue" on "dark green". Thanks! Plastikspork _―Œ^(talk) 20:36, 25 June 2011 (UTC)

User:Frietjes has been de-colorizing hundreds of templates for the sake of consistency, regardless of other considerations and without any discussion with any of the affected parties. A check of his edit history suggests that he will not be affected by the choice of template color for the three botany templates that use green, nor the thousands of matching green taxoboxes. WP:deviations specifically allows thematically-colored variations, as WP:PLANTS has done, and the matching colors enhance professional style over the proposed change to a mismatch. If you believe a change is in order, then you may start (in an appropriate location) and publicize a discussion to change the taxobox color for all the plant kingdom articles.

Your note about CSS is the "in general" situation. The next sentence discusses the variations that are permitted, such as templates for The Simpsons. This example template uses an in-line color variation to override the defaults, not CSS as in the general situation. The Botany template thus follows the same pattern as the explicitly allowed model identified as an exception in policy. --EncycloPetey (talk) 00:18, 26 June 2011 (UTC)

I reworded the explanation at WP:Deviations to prevent such misunderstandings. What really matters is not site-wide CSS, it is accessibility. Templates for The Simpsons use an accessible color scheme, where The Botany template use a color scheme that is not accessible, and that prevents user:Frietjes from reading some of its contents. Dodoïste (talk) 11:50, 26 June 2011 (UTC)

See the parallel current discussion at Wikipedia talk:Manual of Style (text formatting)#Colour. —— Shakescene (talk) 05:32, 26 June 2011 (UTC)

RFC: restructuring of the Manual of Style

Editors may be interested in this RFC, along with the discussion of its implementation:

Should all subsidiary pages of the Manual of Style be made subpages_of WP:MOS?

It's big; and it promises huge improvements. Great if everyone can be involved. Noetica^Tea? 00:25, 25 June 2011 (UTC)

Use of tiny superscripts

I have a hard time the the HTML characters, ² and ³. I'm don't consider myself vision impaired but I do have mature eyes. I can guess at what the symbols are from their context. I find that they usually appear in conjunction with metric units. For example: m³ and km². The {{convert}} template generates m³ and km² using tags. I believe these symbols where once in the box at the bottom of the edit window. They're not there currently but ½, ⅞, etc are. I realize that creating policy does not always change behavior but, if there is a consensus here, the developers of AutoWikiBrowser might be willing to included something in their general fixes. I don't know if it would be possible to replace all the instances where these characters are used but in clear cases, such as when used in conjunction with metric units, it should be fairly simple. Any support would be appreciated. P.S. It is easy to use the template {{frac}} to generate 7⁄8 instead of ⅞. –droll [chat] 21:58, 19 August 2011 (UTC)

Timeline Template is Inaccessible as Graphical Info

recently, i came across the "Timeline" portion of an article, only to discover that since it is a graphic, it is impossible for those who cannot process graphics to obtain the information contained in the "Timeline". This is not only a problem for blind users, but also an important consideration for the partially sighted and those whose visual acuity has decreased due to strain or age, as text-in-graphics tends to become less clear the larger the graphic is englarged...

it would be far better for wikipedia to provide an accessible non-graphic alternative, rather than a @longdesc solution, as wikipedia doesn't allow for actual, meaningful verbose descriptors.

Use of the "Timeline" template should be discontinued and replaced by actual text contained in a timeline whose layout is controlled by CSS oedipus (talk) 01:08, 11 September 2011 (UTC)

I'm confused, the Template:Timeline produces a table with text in it. I can only assume you have a problem with a different template. It would help us to help you if you could say which article causes the problem for you. Cheers --RexxS (talk) 01:47, 11 September 2011 (UTC)

The problem is with the EasyTimeline extension, which has been inaccessible for at least five years. Graham87 03:05, 11 September 2011 (UTC)

User talk:Graham87 is correct -- the information contained in an EasyTimeline is inaccessible to someone interacting with wikipedia exclusively using voice-output (screen reader). i have examined the wikicode behind timelines such as that found on the Minister of Local Government and Regional Development (Norway), for example, and have found the code is FAR more "useable" -- albeit for one who knows wikicode and XHTML/HTML and CSS, that is -- than is the resultant timeline, the contents of which cannot be accessed with a screen reader, even though the wiki code indicates that individual components of the timeline are supposed to function as hyperlinks. also of concern is the immutable color coding contained in the EasyTimeline as well as the purely graphical indication of sections of time. oedipus (talk) 15:06, 11 September 2011 (UTC)

(edit conflict) Thanks, Graham. The discussions at mw:Extension talk:EasyTimeline show the multiple problems with the extension, and the feature request at Bugzilla has been open since March 2006. I think oedipus is right: it's well past time to deprecate this extension and replace it with something more accessible. I'm not sure how commonly this extension is used any more, since trying to follow "What links here" doesn't seem to work. I'm looking at List of products discontinued by Apple Inc.#Timeline of Apple products as an example and trying to evaluate what would be possible. I'm no fan of image maps, but I'm wondering if the simplest workaround is to replace a template like {{Timeline of Apple products}} with a new template that contained the current html output, i.e. an image map and the image. Each <area> element would then be editable to include alt text containing the dates and any other useful text. For what it's worth, that template has 117 <area> elements, but the job would only have to be done once for each template. It's a pity really that anyone would have to be contemplating manually adding alt text to an image map that has been produced programmatically, but as the extension has sat for so long in an inaccessible condition, there doesn't seem to be any interest in fixing the problem at that level. Does anybody know how to get an estimate of how many instances of these timelines exist on Wikipedia? --RexxS (talk) 15:36, 11 September 2011 (UTC)

It'd be fiddly, but that'd be the only way to properly fix the problem. The only way I can think of to find uses of the timeline extension would be to ask someone to use AWB to search the database for the text "<timeline>". Maybe AWB could be used to automatically make those timelines more accessible, if the process is regular enough, but I'm not an expert in this area. Graham87 01:09, 12 September 2011 (UTC)

The <timeline> tag seems to be usually hidden away in a transcluded template, and I suspect the database doesn't expand such transclusions when searching. I'd be pleasantly surprised if it did though! I'll have a look to see if I can find a template that's used in a few places and see how much effort is required to transform it into something accessible. This might take some time ... --RexxS (talk) 21:42, 12 September 2011 (UTC)

The database scanner can search the template namespace. Graham87 00:41, 13 September 2011 (UTC)

For what it's worth, this "template" is (in my opinion) crappy for non-WP:ACCESS reasons too. So anything we can do to make it useful throughout gets my vote. The Rambling Man (talk) 21:54, 12 September 2011 (UTC)

Is the timeline at the top of Center for Biologics Evaluation and Research accessible?

I don't see any mention of "EasyTimeline" at Wikipedia:Graphs, where other options are described. Perhaps it would worth mentioning it as a deprecated option. WhatamIdoing (talk) 15:49, 19 September 2011 (UTC)

I would agree with you, WAID, about mentioning "EasyTimeline" at Wikipedia:Graphs as a deprecated option.

Unfortunately, although the timeline at the top of Center for Biologics Evaluation and Research is not an image, it's not accessible for a lot of people. Have a look at the html output for the page Template:Center for Biologics Evaluation and Research graphical timeline to see why I raise the following issues.

First and most important, the template uses positioned divs to create its output, and as a result all of the divs would be read consecutively up each column by a screen reader producing "1880; -; 1890; -; ... 2010" followed by "Laboratory of Hygiene founded; Renamed Hygienic Laboratory ..." and so on. This would be pretty unintelligible to the listener. Second, because some of the text is at 86%, some visually impaired readers will have to boost the magnification to read it. Finally, because the positioning of the divs uses a mixture of pixels and ems, it is vulnerable to changes in the metrics of the font used, which may vary with different browsers, OS, etc. In my default browser (FF6 in XP) some text overlaps (e.g. "1880" and "The present Centre ...").

It's nice to try to give some idea of scale in presenting a timeline, but it's fraught with difficulties in maintaining accessibility. Personally, I'd prefer to make the information available to all in a table like this:

CBER's past names
Years	Title
1887–1891	Laboratory of Hygiene founded
1891–1902	Renamed Hygienic Laboratory
1902–1930	Became part of the newly formed Public Health and Marine Hospital Service
etc.	etc.

Although it lacks the visual appeal of the current template, as well as failing to visually demonstrate (for example) that the 1887-1891 name existed for a much shorter time than the name during the 1902–1930 period, a table would provide the best chance for making the information available to the greatest number of people. I'm not opposed to having graphically displayed information as it does much to enrich our articles, but I would always insist we ought not to have a graphical display as the only means of accessing that information. Hope that helps. --RexxS (talk) 17:07, 19 September 2011 (UTC)

The net effect of transforming it into a table or text list is that the sighted people who briefly glance over it do not acquire information that they would have acquired instantly from the visual display.

How is it inaccessible? The text in the timeline is all present/in order in the HTML, so presumably it would all be read by a screen reader. WhatamIdoing (talk) 01:04, 20 September 2011 (UTC)

Yes, that's why I meant by the last paragraph I wrote. I already accepted that you wouldn't get instant information at a glance from a table.

I'm sorry I wasn't clearer about the inaccessibility of the present timeline. The text of the timeline in the HTML is completely wrong for a screen reader. Here's the text that a non-visual user agent would be reading:

"1880 — –, 1890 — –, 1900 — –, 1910 — –, 1920 — –, 1930 — –, 1940 — –, 1950 — –, 1960 — –, 1970 — –, 1980 — –, 1990 — –, 2000 — –, 2010 — –, Laboratory of Hygiene founded, Renamed Hygienic Laboratory, Became part of the newly formed Public Health and Marine Hospital Service, Renamed National Institute of Health (NIH), Division of Biologics Control formed within NIH, Renamed Laboratory of Biologics Control, Incorporated into National Microbiological Institute (NIH), Renamed Division of Biologics Standards, Transferred to the FDA; renamed Bureau of Biologics, Merged to form Center for Drugs and Biologics, Split to form the Center for Biologics Evaluation and Research".

Perhaps you can now see that the association between year and name is entirely absent – in other words, that's the price you're asking the visually disabled to pay for having "info at a glance" for the sighted. --RexxS (talk) 01:49, 20 September 2011 (UTC)

Or, it's the price we're paying for not listing the specific years in the labels. There's no good reason why "Laboratory of Hygiene founded" couldn't read "1887: Laboratory of Hygiene founded". That would be more information for everyone. WhatamIdoing (talk) 02:58, 20 September 2011 (UTC)

Indeed, associating the year with the title would be an essential step to improving accessibility – and an easy fix to make. Earlier today I was thinking about this issue and I now believe that the timeline itself (i.e. the years axis) needs to be hidden from a screen reader as it only conveys its information visually. I've made a mock-up of what I think is a more accessible version of the Template:Center for Biologics Evaluation and Research graphical timeline at User:RexxS/Timeline with some of my thinking. It's not a quick job and most of it really ought to be done at the php level on the server, but it should at least show what an accessible timeline might look like. --RexxS (talk) 18:57, 20 September 2011 (UTC)

That mockup sounds much better to me. Graham87 01:43, 21 September 2011 (UTC)

New template requested — Discreet abbreviation

Hello,

See this discussion.

--Nnemo (talk) 23:49, 24 September 2011 (UTC)

Unfortunately, some editors will see that an abbreviation, when marked up as such, may be rendered on their browser with dots underneath. The fact that they may not like that is no reason to stop marking up abbreviations, as using {{abbr}} will allow a screen reader to speak the word in full, improving the experience for visually-impaired readers. The French Wikipedia has a class which hides that effect, but until we have such a class here, we can't make a template to hide the dots, etc. This is not really an issue for Manual of Style/Accessibility, except that it will be difficult to mark up abbreviations properly for accessibility reasons while editors can revert such improvements simply because they don't like how their browser displays abbreviations. --RexxS (talk) 01:46, 25 September 2011 (UTC)

We seem to have a fragmented discussion. Per WP:MULTI, please comment at the original thread. --Redrose64 (talk) 12:27, 25 September 2011 (UTC)

I think we'll have to disagree on that. If there are concerns for MOSACCESS, then this is the correct place to discuss them. I have no idea where the original thread is, but if you mean Category talk:Wikipedia formatting and function templates#New template requested — Discreet abbreviation, then it is appropriate to examine the use of templates there. Please remember that different talk pages attract different audiences and that guidelines like MULTI need to be applied with WP:COMMONSENSE. --RexxS (talk) 14:03, 25 September 2011 (UTC)

The original thread requesting a template is the one which Nnemo linked above, i.e. the same one which you mention. A category talk page was almost certainly the wrong place to request a new template: but there are now something like ten separate threads, all of which direct the reader back to that Category talk thread. Not everyone who sees the original (or another one of the ten) will be aware of this particular direction, so will not be aware that you have posted a comment here. Personally I first became aware of it via a similar post at WP:VPT. --Redrose64 (talk) 14:26, 25 September 2011 (UTC)

History section headings

We should avoid using, in articles etc, section headings of "History", as there already is a link using that wording, on each page, linking to article histries. Alertnatively, the latter should be changed (to "past changes", perhaps), to avoid ambiguity. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 18:16, 20 November 2011 (UTC)

But "History" is just the name of a link, not a form label, so there's not a problem with that section title. Graham87 02:25, 21 November 2011 (UTC)

Documentation heading levels

May I - again - draw your attention to Template talk:Documentation#Heading fix redux. I can't believe this is still dragging on..! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:56, 21 November 2011 (UTC)

Template: United States political party shading

{{United States political party shading}} has very low contrast between text and background colours; it fails WCAG AA luminosity tests. See discussion at Template talk:United States political party shading#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 22 November 2011 (UTC)

Screen reader CSS

Do today's screen readers support CSS such as speak:none or @media speech,aural to avoid reading content while showing it for visual browsers? For example, if "the big red dog" reads out as "the big dog" it works for you; if it reads as "the red dog" it ignores speak:none, and if it reads as "the dog" it honors speak:none but not speak:normal when combined with display:none. And if it reads "the big red dog" it ignores CSS entirely. Anomie ⚔ 15:24, 24 November 2011 (UTC)

As far as I know, the only screen reader that fully supports aural CSS is Emacspeak for Linux. All of my screen readers read the above text as "the red dog": JAWS 10.0, Window-Eyes 6.1 and NVDA 2011.2. I have the latest version of NVDA, and earlier (but still fairly recent) versions of the other two screen readers. Graham87 01:53, 25 November 2011 (UTC)

Thanks for checking. It's disappointing that none of those screen readers support even a bare minimum. Anomie ⚔ 16:25, 25 November 2011 (UTC)

Article feedback tool

The new version of the article feedback tool is currently being tested. I have made a few acccessibility-related comments about it at bug 33081. If anybody has any more comments to make about that bug, or any other issues with the tool (accessibility-related or otherwise), I'm sure that the developers would love to hear them. Graham87 06:55, 14 December 2011 (UTC)

Accessibility of sigs

I've started to draft a page of advice for editors who wish to make sure their sigs are accessible. Please feel free to contribute to its development. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:13, 14 December 2011 (UTC)

I've moved it to Wikipedia:Manual of Style/Accessibility/Signatures. Graham87 02:17, 15 December 2011 (UTC)

It's important to remember that, while accessibility is certainly one of our goals, individual users' signatures are generally not covered by the MOS. We don't want to start hounding users about their signatures simply based on font or color choice. — Carl (CBM · talk) 02:37, 15 December 2011 (UTC)

Who is suggesting hounding anyone? The MoS may not apply to talk pages, and perhaps the page needs a better home, but that doesn't mean that inaccessible sigs don't cause problems for some editors, nor that we shouldn't provide advice for editors who wish to make sure their sigs are accessible. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:21, 15 December 2011 (UTC)

Road junction tables

The accessibility of road-junction tables, of which we have many, is being discussed. You thoughts would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:59, 15 December 2011 (UTC)

NBA color

Many of the colour-combinations used by {{NBA color}} do not meet current WCAG] accessibility guidelines, and so breach MOS:COLOR, because they the foreground and background are not distinguishable from each other. Your comments on how to resolve this are invited, at Template talk:NBA color#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:07, 5 January 2012 (UTC)

Question

There's a question at Wikipedia talk:WikiProject Accessibility#Question_about_accessibility_tag about whether an article about a controversial anxiety-related condition (or its talk page) can be considered "inaccessible" to people who have been labeled as having the condition solely by not being supportive (or by the talk page having a hostile environment).

One of the editors has recently tagged the page as having an {{AccessibilityDispute}} because of the perceived POV of the article and the unfriendly discussions on the talk page. If you have an opinion (either way) about whether this is an appropriate use of this particular template, please share your opinion there. Thanks, WhatamIdoing (talk) 05:42, 3 February 2012 (UTC)

HLIST

There appears to be too much white space when you have something prefaced by **.—Ryulong (竜龙) 20:47, 6 January 2012 (UTC)

"**" creates a nested horizontal list enclosed in parenthesis. The parens are generated as an interpunct and technical limitation in HTML/CSS means the space around any interpuncts cannot be removed. — Edokter (talk) — 21:06, 6 January 2012 (UTC)

I just came here to report the exact same effect.

If an "optimization" produces substandard output, then you don't implement said "optimization".

Chief Programmer and QA Manager Varlaam (talk) 08:55, 21 January 2012 (UTC)

The non-optimised version produces output which is substandard in ways which have a more harmful impact. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:40, 21 January 2012 (UTC)

Nevertheless, you can always change how it looks to you in your own vector.css (or whatever skin you use). Try it out and report your results back here. We'd obviously welcome a Chief Programmer's constructive suggestions on how to make a better implementation of the class. --RexxS (talk) 14:35, 21 January 2012 (UTC)

For those unsure of what this is about, here is an example:

Check the parentheses before "One One", after "One Two", etc. --Redrose64 (talk) 17:06, 21 January 2012 (UTC)

An example of how this looks in practice (that led me here) is Template:Heinz--the extra spaces inside the parens around Beanz and Ketchup: "( Beanz · Ketchup )". Surely there's some technical way to avoid the problem. Seems to me that this non-standard spacing reflects badly on Wikipedia. 71.197.244.119 (talk) 05:10, 16 February 2012 (UTC)

This has recently been brought up at MediaWiki talk:Common.css#Small bug, because the styling for a hlist is defined in MediaWiki:Common.css. --Redrose64 (talk) 09:25, 16 February 2012 (UTC)

Screen reader user input needed

Editprotected at Template talk:Rating#New template code removed some alt= stuff from this template that earlier discussion on that page had tested and in both text-only and screen-reader browsers. New version has no alts at all. The changer of the code sandboxed it for text-only compatibility, but I strongly suspect that the changes have undone badly-needed code for screen-readers. It would be helpful if someone ran the current version and the version from 2010 through some screen-readers and informed the template talk page what the problems are, if any. I think the lack of blank alt's will cause screen readers to read out the filenames, and other user-hateful behavior. — SMcCandlish Talk⇒〈°⌊°〉 Contribs. 05:58, 20 February 2012 (UTC)

daggers

I read the archive on daggers and I have a question about screen readers. Maybe they've changed a bit since the special character section was written but it pretty much says that screen readers have trouble with ALL non-Latin 1 characters... turning them into ?. That would include endashes and emdashes wouldn't it? If so it would be incredibly bad to to have to change a simple "–" into {{ndash}} in tennis articles as the time to do it would be ridiculous and it could effectively double the length of some articles and lists. Especially with wikipedia pretty much systematically changing all the old &ndash stuff to the character "–". Daggers and card suits aren't used all that much so it's probably no bid deal to use {{ }} for those, but changing ndashes would be a big mistake. Has anyone thought of talking to JAWS people to ask if fixes are in the works? Fyunck(click) (talk) 20:37, 21 January 2012 (UTC)

It might be worth checking with Graham87, but I think JAWS silently drops a lot of punctuation, and I wouldn't think a screen reader user would lose much information if they didn't hear anything where an ndash was used. The same goes for most non-Latin 1 characters, unless they are being used as a key to convey information. An example would be a list of the players in a cricket team where the wicket-keeper is marked with † and a JAWS user would have no indication of which one it is, because it drops the symbol silently. It's in those cases where a template like {{†}} which produces an image + alt text is valuable. I don't think anyone would see any benefit in replacing ndash with a template in normal running prose. --RexxS (talk) 03:34, 22 January 2012 (UTC)

Why on earth isn't this user-configurable? I'd be mad as hell if my browser ignored certain crucial punctuation like en-dashes. I'd much rather, for "3–12" hear "three dash twelve" than "three twelve" or gods forfend "three question-mark twelve" of all things. — SMcCandlish Talk⇒〈°⌊°〉 Contribs. 06:03, 20 February 2012 (UTC)

I'm not sure how, but this page slipped off my watchlist for the last month or two. Windows screen readers read – and — correctly because it's part of the Windows-1252 character set; I don't know about other operating systems, but I assume that modern screen readers can handle the characters correctly. How punctuation is spoken by screen readers is user-configurable, but fine-grained control can be difficult. Graham87 13:26, 7 March 2012 (UTC)

Layout tables

The section on layout tables says:

Avoid using tables for layout purposes only … For simple layouts tables can be an option…

This is contradictory. Shall we remove the latter paragraph, and that which says "…when using tables for layout purposes…"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:04, 25 February 2012 (UTC)

Or soften the "Avoid" language at the start, perhaps? Graham87 13:32, 7 March 2012 (UTC)

Accessibility of lists at "Five pillars" page

The subject line says it all. Please see Wikipedia talk:Five pillars#Accessibility problem with this page. Graham87 13:35, 7 March 2012 (UTC)

Ice hockey boxes

All comments welcome at Wikipedia_talk:WikiProject_Ice_Hockey#Accessibility. Frietjes (talk) 22:03, 8 March 2012 (UTC)

Superscript, subscript characters

I recently reverted a person who had it seemed removed the superscript tag round some plus and minus signs, but in fact they had put in the unicode signs ⁺ and ⁻ instead of the ⁺ and ⁻ and I had misread them as my browser had them looking more like the non superscript signs. The questions are, how good is Unicode support nowadays in accessibilty software, do these come out okay. Does the section on text in the manual of style really just refer to foreign symbols or is it out of date? Aee you happy with the use of characters like these?

Plus   was replaced by the unicode character ' ', is that okay? I can't see the difference between that and a normal space in the editor and it worries me. Dmcq (talk) 14:32, 18 March 2012 (UTC)

The section about text in the Manual of Style is still applicable. The unicode superscript characters should not be used. Graham87 01:54, 19 March 2012 (UTC)

It will always be preferable to use the simplest possible characters because of older readers still being in use. So ASCII should be preferred to Unicode unless there's an overriding reason to do otherwise. Also, although Unicode characters are preferred to html entities (for readability reasons in editing), the exception to that is obviously   since the character is indistinguishable from a normal space and therefore   should be used for a non-breaking space. In situations where large numbers of   would be used, it is probably better to set a "nowrap" style or use the {{nowrap}} template. Hope that helps, --RexxS (talk) 02:23, 19 March 2012 (UTC)

Okay thanks very much, that seems a fairly negative opinion on general use of Unicode for subscripts and superscripts and it should only be used if it is reasonably obvious one should be using it. Dmcq (talk) 21:36, 19 March 2012 (UTC)

style="font-size:... vertical-align:..." for super/subscripting

While helping another editor debug a page-rendering issue, I noticed that {{chem}}, via the {{su}} back-end, uses font-size and vertical-align to create the effect of super- and subscripting rather than and tags. The positioning has actual meaning in this context (super vs sub vs inline). The templates do a type of positioning that is not possible with ordinary wiki markup (super and sub text horizontally-aligned with each other), so it really needs some sort of tricky solution to get the formally correct display (however, the horizontal alignment is not required for the meaning). Is this accessible, or do non-traditional browsers lose these key positioning attributes? DMacks (talk) 19:25, 22 March 2012 (UTC)

While looking for alternative implementations, I just noticed {{SubSup}} gives the same type of output effect for use in places where super/sub/inline has meaning and also uses the same font-size/vertical-align method as {{su}}. Yay for reinventing wheels? DMacks (talk) 19:33, 22 March 2012 (UTC)

Ewwww! These are not accessible at all. Screen readers would not detect these as superscripts or subscripts; they would detect the change in font size, though the meaning of that would be unclear. Graham87 07:13, 23 March 2012 (UTC)

Is this approach better? "²
₁H⁺
₃ is a trideuterium monocation" (a pathological case with a super/sub pair before and after normal text) and "water is H
₂O" (a simpler case). They use real superscript and subscript tags, but also some unusual span formatting and linebreaks. Do those games interfere with readers? DMacks (talk) 08:06, 23 March 2012 (UTC)

The line breaks interfere with screen readers, but the unusual span formatting would be OK. Graham87 14:22, 23 March 2012 (UTC)

Snooker templates

Some folks might be interested in commenting on accessibility issues with regard to the formatting of snooker templates (see Wikipedia talk:WikiProject Snooker#Template changes). Thanks! Plastikspork _―Œ^(talk) 03:33, 30 March 2012 (UTC)

yes, more input is needed. 134.253.26.12 (talk) 17:51, 30 March 2012 (UTC)

Question about symbols

It is stated that unpronounceable symbols should not be used, however some people use the ♠, ♣, ♥, and ♦ symbols to indicate suit when describing hands of a card game, especially poker. For example, a hand containing the nine of clubs and the three of hearts might be written as 9♣ 3♥. Is this acceptable? 76.181.160.60 (talk) 21:00, 30 March 2012 (UTC)

Really they should use the proper suit templates {{spades|A}} {{hearts|K}} {{diamonds|Q}} {{clubs|J}} → A♠ K♥ Q♦ J♣ --Redrose64 (talk) 21:22, 30 March 2012 (UTC)

Unfortunately the suit templates are no more accessible because they simply use the unpronounceable symbols ♠, ♣, etc. It means that a visually impaired visitor using a screen reader will not know the suit and the article will not make sense to them. I'd prefer to see images with alt text used in the templates, but sadly small images can rarely be zoomed without becoming 'fuzzy', so someone is sure to complain about that. --RexxS (talk) 22:58, 30 March 2012 (UTC)

For what it's worth, JAWS 10 pronounces the diamond character "♦" as "black diamond suit", but doesn't pronounce the other three suits correctly, which isn't very helpful. Graham87 06:29, 31 March 2012 (UTC)

The templates are styled using the CSS class="spades", class="hearts", class="diamonds", class="clubs" respectively, but I don't know where those classes are defined, nor what they contain. It should be possible to add something either to these classes or to the suits templates which will be ordinarily invisible, but which is interpreted by screen reader software as something to be read out aloud. --Redrose64 (talk) 16:07, 31 March 2012 (UTC)

As far as I can ascertain, those classes are not defined anywhere, and don't contain anything – at least they don't show up in either Chrome's 'Inspect element' or through the 'Web developer' addon for Firefox. I assume the template adds those classes to allow the possibility of styles being defined for them (either in common.css or in a user's personal css). If you're looking for something that's ordinarily invisible, but which a screen reader reads aloud, then it might be worth reviewing Wikipedia talk:Manual of Style/Accessibility/Archive 11#Non standard ASCII where that elusive technique was argued about extensively (including the problems of printing the page on paper), and the only solution that could be found was an image + alt text. I'd be more than pleased to see any other alternative solution that anyone could come up with. --RexxS (talk) 22:06, 31 March 2012 (UTC)

Image size discussion at Manual of Style talk

For those who don't follow Wikipedia talk:Manual of Style religiously, there's a low-key, practically-oriented, discussion of how to specify the dimensions of images at Wikipedia talk:Manual of Style#Image size. The percentage specs I use in tables (e.g. width="8%"), partly following the accessibility advice given here, will apparently not work in HTML 5 —— Shakescene (talk) 10:32, 1 April 2012 (UTC)

Template:Infobox single and tag

It was raised up on Talk:Picking Up the Pieces (Paloma Faith song) that it is apparently a visibility issue in the infobox to wrap "(Album version)" and "(Radio edit)" (identifying the two different lengths of the song) with the  tag. This formatting appears to be in place in several articles, already, and on several featured articles (mentioned on the article's talk page); I am sure it is written in some manual of style, but I'm not sure which one, and otherwise it would not be as widely applied. What is the wider opinion here? Is having (Album version) within a template problematic or not?—Ryulong (竜龙) 22:23, 8 May 2012 (UTC)

There is no accepted guideline specifying a minimum font size on Wikipedia. There are several discussions, such as at Wikipedia talk:Manual of Style/Accessibility/Data tables tutorial #Minimum font-size recommendations that indicate concern for fonts below about 85% of normal size, with many editors finding those difficult. The  tag will produce text about that size by default, but registered users can set a different size for "small" text in their own css, in a similar way to that described at Wikipedia:WikiProject Usability/Readability guidelines, which examines many of the factors involved in this issue. In addition, most modern browsers can use ctrl+ to increase zoom and ctrl- to decrease it (or the equivalent on a Mac), so the problems of small text are more of an inconvenience rather than a barrier.

Having said all of that, personally I'd still discourage the use of text significantly less than 100% size on Wikipedia, with the exception of wherever space is limited – like an infobox, for example, but in those cases I'd recommend using something like , rather than  to mark it up since the latter is semantic markup intended to convey a meaning, not to fit text into a space. --RexxS (talk) 01:04, 9 May 2012 (UTC)

But is there anything wrong with using this smaller text in this particular template that three featured articles may suddenly not pass the accessibility standards?—Ryulong (竜龙) 08:09, 9 May 2012 (UTC)

No, the accessibility standards have evolved gradually, and have not traditionally been part of the FA criteria, so I'm afraid that being a featured article is no guarantee of the accessibility of an article. As I said, the smaller text would be an inconvenience for some, but not a barrier. Only the editors who know the subject matter well can balance the desirability of smaller text against the (minor) problems it causes for some viewers. --RexxS (talk) 11:09, 9 May 2012 (UTC)

Heads up about problem with template converted to use plainlist

Please see my message at Template talk:Shortcut#Changing wiki-markup to pure HTML in lists. Graham87 07:51, 9 May 2012 (UTC)

something that might be of interest to the editors here

Wikipedia:Deceased Wikipedians#Claude A. R. Kagan (Claude A. R. Kagan) came up at ANI and I hastily added him to that list according to the request and that was as much as I wanted to do. I came across this page and thought there may be people here interested in his work on wiki, or interested in Mr Kagan, who is notable enough for a biography article I expect. So that is that for what its worth. Penyulap ☏ 02:13, 22 May 2012 (UTC)

Signature colour argument

There is an argument about the use of colours in editors' signatures. Pleas comment here. Axl ¤ [Talk] 21:59, 27 May 2012 (UTC)

Hlist separators

When will those be coming back? It's been months.
Talk about fixin' somethin' that wasn't broken.
Every hlist now is a bloody disaster scene which can no longer be read at a glance.
Varlaam (talk) 18:43, 28 May 2012 (UTC)

Hlists should have bullets as seperators. What browser are you using? — Edokter (talk) — 16:20, 29 May 2012 (UTC)

Timelines

see Wikipedia:Templates for discussion/Log/2012 May 30#Template:Timeline of Nunavut Premiers. thank you. Frietjes (talk) 16:44, 2 June 2012 (UTC)

Headings: avoid pseudo-headings

Hi. I've just added a guideline about avoiding pseudo-headings.

I'm not 100% sure if it is currently needed. But I recently saw an active user who claimed that pseudo-headings were fine since he read about it in Wikipedia: The Missing Manual. I'm going to fix this mistake in the manual.

Any thoughts? Dodoïste (talk) 00:56, 3 June 2012 (UTC)

I think that "never" might be too strong. If you've got a huge section that seems like a long gray blur of text—a problem that can't affect people who can't see the gray blur in the first place—then providing visual breaks is a good thing for sighted users and harmless to unsighted users. "Blah blah blah blah Bold-faced topic sentence Blah blah blah" might help a sighted user (especially someone with dyslexia) keep his place in the text, and should be no different for users of screen readers than "Blah blah blah blah Roman-faced topic sentence Blah blah blah".

Additionally, if you want to solve the problem at its likely root, then you probably want a pointer to the instructions on how to limit the depth of the table of contents, because I suspect that keeping the TOC from taking over the article is a significant reason for avoiding navigable headings. WhatamIdoing (talk) 01:05, 3 June 2012 (UTC)

I have amended the guideline according to your advice.

I'm not sure I understand your example about bold. A few bold words in a paragraph is fine. But I've never seen a whole bold sentence that was useful, could you provide an example? And I don't understand the relation between bold text in a paragraph and a pseudo-heading made with bold. Yours, Dodoïste (talk) 01:21, 3 June 2012 (UTC)

Proposal to change alt text for thumbnails

Please see bug 34750, about a proposed change to alt text for thumbnails. Graham87 15:51, 3 July 2012 (UTC)

Replied at Wikipedia talk:WikiProject Accessibility#Changes in thumbnail alt text. Dodoïste (talk) 18:34, 3 July 2012 (UTC)

Proposed change: Resolution

This advice about screen resolution is good, but users with a handicap are concerned by this need in the same way than normal users. And some disabled people are more able than us in this regard, especially the blind. They don't seem to care about screen resolution, strangely. :D

Jokes apart, I feel it would be more relevant in another MoS page. Maybe MoS:Layout, because it is solely a layout issue. Thoughts? Cheers, Dodoïste (talk) 19:27, 21 July 2012 (UTC)

I'd be resistant to this.

If I were to describe the point of this page in a sentence, to someone who is annoyed that I have suggested that they add alt text or row and column scopes, I would say: "The purpose of WP:ACCESS is to ensure that reasonable steps are taken to accomodate those with special browsing needs; to try to produce our content for everyone." While catering screen resolution doesn't fit into most online definitions of accessibility, it does fall under the more general principle of producing content for everyone. This guideline, when enforced, carries more weight than any other section of the MoS, and rightly so. To put the section anywhere else would be to weaken it. —WFC— 19:50, 21 July 2012 (UTC)

OK. But it will have to be improved then. Are users really able to male any use of this guideline? I mean, what tools do they use to check a 720px resolution? Should we provide such a tool?

Another problem is the lack of external source. You see, I am attempting to give more credibility to this guideline by following W3C's WCAG 2.0 methodology.

Every guideline is detailed, explained and updated on W3C's website. I've already done this with MOS:DTT. Concerning this advice about resolution, I do not have a trusted source to add in the references. I haven't searched yet, though. But later on, this section might be questioned due to the lack of sources.

I'll try to improve this section about resolution, then. Dodoïste (talk) 15:12, 22 July 2012 (UTC)

Concerns about ensuring that our content is accessible by as many people as possible extend beyond WCAG. Many readers in less developed countries have small screens, old browsers, and low bandwidth, but generally we can anticipate the problems these cause and attempt to work around them. This page is surely the best place to give guidance on how to do that. As far as tools to test resolution are concerned, I'd recommend the "Web Developer Toolbar" addon for Firefox that allows you to set any window size you choose for the browser. That lets you see how a page would look in different resolutions. --RexxS (talk) 22:03, 22 July 2012 (UTC)

Understandable point of view. But how are we supposed to know which minimum resolution we should allow? After a few years, won't we become able to set the limit to 1024px ? Is it nit the responsibility of the developers to build a CSS3 responsive layout that would work with every screen and devices - with only one version?

If we are meant to keep this guideline, I agree that the web developer extension for Firefox is a great idea. Cheers, Dodoïste (talk) 17:03, 23 July 2012 (UTC)

Proposed changes for the "article structure" sections

Hi. The recommendations about the "lead section" and the "section structure" are fairly correct, but I believe they are not in the right page. It basically says that articles structured in a standardized fashion (infobox always at the top, and such) improves accessibility. That's right, but it helps everyone too. And it's already achieved by other MoS guidelines and the habit of Wikipedians to standardize things.

All in all, I believe theses sections are not needed. I suggest to remove them. Shortening this MoS to the essentials is a good thing, it will help focusing on the things that matter the most. Any thoughts or objections? Cheers, Dodoïste (talk) 19:36, 20 July 2012 (UTC)

Strongly in favour of removing them from here, although it would be worth dropping a note at the main MoS talk page to see if they want to port anything over to another page. —WFC— 20:01, 20 July 2012 (UTC)

Hm, that's a question to consider indeed. Aren't Wikipedia:Manual of Style/Lead section and Wikipedia:Manual of Style/Layout more detailed on this matter than our little summary here? Would it be worth adding a sentence like "a standardized layout also improves accessibility"? I believe that people are going to apply this layout guideline regardless of accessibility, so I'm not sure it's worth mentioning. But if you believe it is worth it, then OK, I'll drop a note at the MoS talk, definitely. Cheers, Dodoïste (talk) 00:14, 21 July 2012 (UTC)

Linking to main locations (with an {{also}} link or similar), is definitely preferred, instead of duplicating the content. Less repetition, less errors/divergence, less overwhelming. -- Quiddity (talk) 23:53, 20 July 2012 (UTC)

After some thoughts, I felt some explanations might be useful, while avoiding to duplicate contents. Feel free to rewrite and copyedit as you feel necessary, I'm still not a native speaker. Cheers, Dodoïste (talk) 17:42, 21 July 2012 (UTC)

For what it's worth, the recent edits sound good to me. I've slightly copyedited the new text. Aloha from Hawaii! Graham87 01:05, 25 July 2012 (UTC)

List of The Simpsons video games

Do the colors in the table abide by this guideline? It's currently at FLC and it's been brought up that it could possibly be an issue, but we aren't sure for certain. Please direct all comments on the matter on the FLC page and not here. Thanks in advance. Statυs (talk) 17:17, 5 August 2012 (UTC)

Use of "rowspan" in tables

Hello. The Actors and Filmmakers WikiProject currently advises against the use of "rowspan" in filmography tables and cites it as an accessibility issue from this essay. The essay, written in August 2010 cites that the use of rowspans in certain circumstances can make information confusing when using a screen reader. I am not fully aware of how these screen readers work and would like to confirm if this information is still relevant. I am signifying RexxS of this discussion as well. BOVINEBOY2008 21:28, 27 August 2012 (UTC)

Screen readers are getting better all the time and JAWS (screen reader), currently at version 13.0, will cope with both rowspans and colspans very well in the simple tables we tend to use in Wikipedia. Nevertheless, older screen readers may sometimes not give the anticipated results, especially if the rowspan is in the first column of the table. Also, the points I made in the essay about the older and simpler technology still apply. For example, I have a good friend who has 1/6 vision and doesn't need something as complex (and expensive) as JAWS. When he can't quite make out the text, he often uses text-to-speech (like Dragon Naturally Speaking or the one built-in to Opera) and they don't cope well with rowspans as you can hear in the essay. The Royal Society for the Blind recommends testing using a text-only browser like Lynx (web browser), because if it works on Lynx, it is pretty much guaranteed to work anywhere, but text-only browsers are much less common nowadays - they used to be commonly used on low-bandwidth connections where images were not practical. Lynx can't distinguish between an empty cell and a cell that is part of a rowspan, which can lead to ambiguity, so you shouldn't leave any other cells empty if you want to use rowspans and be as accessible as possible.

In brief, rowspans don't have to be banned, but if you're going to use them, please try to balance the possibility that they might cause difficulty for some visitors against using them only because you think it "looks better". The advice from the Actors and Filmmakers WikiProject is sensible, even if we don't have hard and fast rules. Hope that helps, --RexxS (talk) 22:02, 27 August 2012 (UTC)

I don't want to interfere in your decision, as there is a sensible rationale behind the point of view of RexxS. Refraining from using rowspans is going to benefit to some people, that much is certain.

But I have to state that the use of rowspan in tables in not discouraged in MOS:DTT, because it is not an official requirement for accessibility. Up-to-date technologies support rowspans, and JAWS have supported it since 2006. Some assisstive technologies are also responsible for being outdated. Based on this, you can choose your own answer to your question. If it doesn't take you too much time or if you enjoy doing it, I would say "go right ahead". :-) Dodoïste (talk) 22:48, 27 August 2012 (UTC)

I have to say I like rules myself, but I can go with the flow if I have to. Bovineboy kindly started this topic in response to him removing rowspan from many articles, my questioning it, him pointing to the essay, and my wondering if the essay is "outdated". I see many editors taking different positions on this issue, and I would prefer that we at least have a guideline rather than we can do whatever we like. For example, what happens if a table has rowspan, and an editor removes it, can someone else revert? That problem and its many permutations can cause problems.--Bbb23 (talk) 00:47, 28 August 2012 (UTC)

Although it does not matter too much, I do think we should have some sort of guideline suggesting to use or to avoid using this feature of tables. I do think it is mostly used for aesthetic value and it definitely can inhibit accessibility for both screen readers and inexperienced editors. BOVINEBOY2008 01:26, 28 August 2012 (UTC)

@Bbb23: that's the reason why this is in an essay and not a guideline. It means: if there is consensus for removing rowspans, go ahead. If it looks like it will lead to much trouble, edit disputes, and such don't do it. This issue is not worth fighting over it, in my opinion. Cheers, Dodoïste (talk) 10:20, 28 August 2012 (UTC)

It is a guideline, as it's part of the Manual of Style. However I agree that this particular issue isn't worth fighting about. Graham87 14:47, 28 August 2012 (UTC)

Does rowspan still also break table sortability? Especially for tables of data that might have various orderings of interest to readers, that's a separate usability issue that affects everyone. DMacks (talk) 15:45, 28 August 2012 (UTC)

Here's the first demo table from Wikipedia:WikiProject Actors and Filmmakers #Filmography tables with rowspans inserted for the years:

List of acting performances in film and television
Title	Year	Role	Notes
Barabbas	1961	Patrician in Arena	uncredited
Hemingway's Adventures of a Young Man	1962	undetermined role	uncredited
The Beverly Hillbillies	1963	Janet Trego	TV series, 15 episodes
Mister Ed	1963	Telephone Operator Sailor's Girl	TV series, episodes: "Love Thy New Neighbor" "Ed Discovers America"
The Americanization of Emily	1964	Beautiful Girl	uncredited
The Man from U.N.C.L.E.	1965	Therapist	TV series, episode: "The Girls of Nazarone Affair"
Eye of the Devil	1966	Odile de Caray
The Fearless Vampire Killers	1967	Sarah Shagal
Don't Make Waves		Malibu
Valley of the Dolls		Jennifer North
Rosemary's Baby	1968	Girl at Party	uncredited
The Wrecking Crew	1968	Freya Carlson
The Thirteen Chairs (also known as 12+1)	1969	Pat	released posthumously

Try sorting it a few times on different columns and see if it works for you. I'd be amazed if it did. Hope that helps, --RexxS (talk) 20:37, 28 August 2012 (UTC)

It doesn't work on Firefox 14. Contents in the years and role columns get mixed up in the wrong columns.

@Graham87: I was referring to User:RexxS/Accessibility, which is an essay and is not included in MOS:DTT on purpose. Cheers, Dodoïste (talk) 23:14, 28 August 2012 (UTC)

Accessibility of sigs

The accessibility of user sigs is being discussed at Wikipedia talk:Signatures#Simplifying signatures. Your views would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 4 September 2012 (UTC)

Track listing template

Theres a disucssion at Template_talk:Track_listing#Minimum_Size about increasing the font size of notes on the template. — Lil_℧niquℇ №1 ^[talk] 16:35, 11 September 2012 (UTC)

it would be great to have some more input at Template talk:Neopaganism-sidebar concerning the various versions of the template: [1], [2], [3], [4], [5]. Frietjes (talk) 23:03, 11 September 2012 (UTC)

Small print

Possibly one of the most widespread accessibility issues is defective eyesight - estimates in the billions for the population with refractive errors have been made. For this reason we should avoid small print, and yet there is nothing in the accessibility guide about this. Should there be? Rich Farmbrough, 06:08, 15 September 2012 (UTC).

This is not classified as an accessibility issue, because these people are not classified as "people with disabilities". Thus the WCAG guidelines we follow here does not have requirements for the size of text. It is rather a usability issue, see Wikipedia:WikiProject Usability/Readability guidelines.

For example, I am shortsighted (-5 both eyes), and my glasses reduces the apparent size of the objects around me. Witch means that the text appears smaller to me. I often increase the size of the text when browsing the internet, up to 125%. It makes it much more comfortable. This is a usability issue that lots of common users experience. Dodoïste (talk) 09:53, 15 September 2012 (UTC)

Sorry to disagree, but considerations of accessibility cannot be restricted to those who have somehow become "classified as people with disabilities". It is clear that someone who has a vision defect does in fact have a disability:

Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.
— http://www.w3.org/TR/WCAG/#intro

This shows that WCAG is a good starting point, but acknowledges its shortcomings. We are free to build upon their recommendations, and we should be encouraging our editors to do so. For example, we know that only around 5% of editors are over 50, and it is difficult for many younger editors to understand the problems caused by lack of accomodation, which inevitably occurs with ageing. Although we now expect user agents (e.g. browsers) to allow text resizing, we should still be conscious of the inconvenience of frequently having to adjust zoom level - along with the nuisance of losing place in a long article - simply because an editor set too small a text size for older readers. I could almost suggest this is an age-discrimination issue: we are happy to take positive action to try to appeal to female visitors, but ignore the needs of older visitors (and as editors they are just as under-represented proportionately as female editors are).

I usually try to make sure that text below 85% doesn't appear adjacent to 100% text anywhere where the visitor is reading continuous prose. In infoboxes, it's sometimes sensible to compromise, but I think that we should minimising the number of times we expect a visitor to change zoom level on any page. --RexxS (talk) 15:41, 15 September 2012 (UTC)

Whatever the advice is classified as (Accessibility or Usability) it should indeed be made clearer, and more easily linked/referred to (ie a shortcut like MOS:TEXTSIZE or something).

The only things we have right now, are the last 2 sentences of WP:Deviations, which don't even mention the widely used {{Resize}} and its variants. (Semi-related discussion at WP:VPT#Font size.)

Standard practice seems to be "90% as a recommended minimum", which is based on OS/browser-consistency at that size (see User:Edokter/fonttest/screenshots), and taking our other default styles into account, so as to annoy the least amount of readers. (And there are years of argument/debate about it, centered around {{reflist}}. So I assume there is ample evidence and consensus for 90%.) —Quiddity (talk) 20:42, 15 September 2012 (UTC)

@RexxS, you are right. It is true that accessibility indirectly benefits to a much broader audience than the disabled. I meant to say that the WCAG does not have any guideline on this subject, rightfully so. This means that we have no clear reference to support our claims at the moment. We don't have a threshold for success, like "text should be at least this size". But we have some usability references that recommend to care about this issue, which is much more vague.

@Quiddity: Yes, it would be good to have such a recommandation in the MoS. I don't know on which page. And there is a need to discuss this issue with the community at large before adding such a thing to the relevant MoS page. Using the following references might help moving forward the debate. In Nielsen's 2005 study, 2/3 of the users complained about the small size of the text. See also 5 Painless Usability Fixes and Select Easy-To-Read Fonts. Dodoïste (talk) 13:09, 16 September 2012 (UTC)

The community has been discussing the issue of text/font sizes for at least five years without agreeing a recommendation. A couple of quick searches shows :

I'm sure there are more, but those discussions are a good starting point for gauging the feelings of many of the concerned editors. --RexxS (talk) 17:31, 16 September 2012 (UTC)

I think its time Wikipedia adopted a universally accepted minimum text size and then phases out things like and replaced with {{small}}. — Lil_℧niquℇ №1 ^[talk] 18:28, 16 September 2012 (UTC)

Link color in sidebar templates

see Template talk:Nanotechnology. thank you. Frietjes (talk) 23:42, 17 September 2012 (UTC)

Struck-though text

There's a discussion of use of struck-through text, at Talk:Nanjing Dajiaochang Airport#Struck-through content. Your views would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 19 September 2012 (UTC)

Template:DRC Muzito Cabinet I

I attempted to convert this to something that would work with variable browser widths, but my attempts were reverted citing accessibility. any ideas or suggestions are welcome. thank you. Frietjes (talk) 16:54, 11 October 2012 (UTC)

Just like Br'er Rabbit who restored your changes, I believe it is an improvement in accessibility. It removes nested tables (per guideline Avoiding nested data tables), makes uses of a list instead of a long table, and has a better display on mobile browsers and such.

However, it might reduce readability for the average user. Could we find a way to keep the columns, in an accessible fashion? Now that HTML5 is enabled on Wikipedia, we might find a satisfying solution. Dodoïste (talk) 17:27, 11 October 2012 (UTC)

Yes, it's simple as hell. Just add a DIV, the corresponding class (column-2... until column-5 depending on the number you want) aaaand it's DONE. And accessible. Awesome.

But we will have to fix Template:Columns and its uses, because it still uses tables for columns. Evil. Dodoïste (talk) 17:35, 11 October 2012 (UTC)

(Edit conflict) Table format is the best way to lay out some types of data, since the reader can quickly scan scan down the rows to find the entry they are looking for. If the table entries are collapsed into unformatted run-on text, it is harder to locate specific items. This template was created in table format, then changed to collapsed format. Either way, with progressively smaller windows the reader is first forced to scroll vertically, and then to also scroll horizontally. It would be nice to avoid scrolling, but not an overriding priority. What counts is how easily the user finds what they want. The table format is much easier to read, even on small mobile screens where scrolling is needed. (A check on the Lynx browser shows the table format rendering well - much cleaner than the collapsed format.) If there is a simple way to get the table to adapt better to the screen size, that would be good though. Aymatth2 (talk) 18:10, 11 October 2012 (UTC)

I absolutely agree with your point about scannability and readability. That's the reason why I suggested a version with columns, while keeping it accessible at the same time. But it was reverted, so this proposal will have to be discussed further. Dodoïste (talk) 18:23, 11 October 2012 (UTC)

This series of templates (like Template:DRC Muzito Cabinet II) are not worth having - ...dominated by red links (WP:REDNOT).Moxy (talk) 18:55, 11 October 2012 (UTC)

If these are being steadily developed with new articles on these various ministers, I've little problem with the redink. It certainly may be the case that some are unwarranted. Br'er Rabbit (talk) 19:18, 11 October 2012 (UTC)

Redlinks should not be created if they point to articles that are very unlikely to be started. I would like to believe that bios of contemporary DRC cabinet members are likely to be started, have started several myself and expect to start more. Aymatth2 (talk) 19:26, 11 October 2012 (UTC)

The table format in this template assumes the mobile user will scroll as needed, but is sized so most PC users do not have to. The collapsed format attempts to reduce mobile scrolling by cramming all the content into a blob of unstructured text. The attempt is futile: the mobile user will still have to scroll. They had to scroll to get down to the template at the foot of the page in the first place, and they will have to scroll to scan the template contents. On almost all mobiles it is as easy to scroll horizontally as vertically - a flick of the thumb or click of a key. Collapsing the template to eliminate horizontal scrolling has just made the data harder to access. The template should be reset to its original state before it was changed without discussion, and no format changes should be made until we have consensus here on the best target format. Aymatth2 (talk) 19:26, 11 October 2012 (UTC)

Anything columnar, regardless of implementation, will result in horizontal scrollbars for a fair number of readers. Aymatth2's and Dodoïste's stuff have them at sizes of netbooks and small laptops, as did Frietjes's version until I added {{allow wrap}} in the |below= links. WP:HLIST is the key thing in play here and it's taken over most navboxes in the last year. It still has a few kinks, although Edokter recently did some v2.0 to it... For mobiles, it needs an escape from white-space:nowrap on list items either per sniffing the screen res or a class-modifier. This is what most uses of {allow wrap} have been about and too often people put crazy-long item in lists that don't wrap (I've see up to about 160 characters). Any columnar arrangement should adapt to progressively smaller viewports by reducing and then omitting all columns as needed, and I don't think we have that solution in hand. The whole point of HLIST is about proper structure; html list of various sorts. It most definitely not about being unstructured or unformatted. Horizontal scrollbars are a thing that users absolute *hate*. Years of usability studies have shown this. People are used to vertical scrollbars, but not horizontal ones and many have no idea how to find the rest of the screen (this not really about mobile users, who are too often forced to cope). Br'er Rabbit (talk) 19:44, 11 October 2012 (UTC)

Vertical scroll bars are much easier than horizontal on Windows PCs because the mouse has a vertical scroll wheel. That concern does not apply to mobiles, where the user can equally easily scroll horizontally or vertically. The smartphone user may well prefer a few "large" pages that they can explore in both directions to many small ones. The layout of a page should of course avoid problems like a long line of text that cannot be seen in its entirety. The table format of this template meets that criterion since each label-data row is quite short. It is easy to read on a smartphone.

In a sense, the original table of ministers was "long and thin" - a lot of short label-data rows. I would like a way to say that the table should automatically divide itself into two, three or more columns of label-data rows, but only if there is space. Sort of like {{reflist|colwidth=30em}} The table format version of this template shows the effect when there is room for four columns. If the screen is narrower, there should be less columns. But there is no need to go too narrow. With mobiles, horizontal scrolling is just as easy as vertical.

The collapsed format version of the template is, in my view, the worst of all worlds. Alternating labels and data in an hlist with a combination of black bold, blue and red looks really amateurish and is very hard to read. Far better to line up the label-data columns and occasionally force horizontal scrolling than to inflict this horrible mess on everyone. So how do we get formatted label-data columns that use available space efficiently and do not require horizontal scrolling on devices with click-and-drag scroll bars? Aymatth2 (talk) 20:56, 11 October 2012 (UTC)

Not all mice have wheels and not all mobiles scroll as easily as say a iPhone. It's often a pain with a basic model. And these nest tables and columns require horizontal scrolling even at 1280px widths. It's user-hostile.

The bold on the ';' term is unfortunate and I'm not fond of it. It can be kicked with {{nobold}}. Edokter insisted on keeping it as the default because it's the default for normal dl/dt (';'/':') structures. See the next section where I comment on columns adapting to screen res. That's what {{reflist}} can do. <table> simply don't do that; is works on <div> (and some other elements) can use the CSS column properties to adapt. But this is not well developed on wiki (subject to exploring those templates mentioned that I'm unfamiliar with). I've done this a lot on real websites. Designs can be made to significantly adapt to the platform content is being view on; it's work. WMF is doing more of this lately for mobile. These navboxes are anomalies. Normal navboxes are simply doing hlist, these days. There's the idea of subgroups, but they too have width issues. The whole mess does stem from navboxes being based on tables. That made years of mess that will eventually have to be changed simply because the structure is wrong. Wiki does a lot wrong :/ Br'er Rabbit (talk) 23:26, 11 October 2012 (UTC)

I swatted the bold. Br'er Rabbit (talk) 23:30, 11 October 2012 (UTC)

Well I just learned something. I checked what {{reflist}} generates, and found column-width, -mos, -webkit. I checked what that meant and found "not IE". Looking at a page I wrote in IE, I found no {{reflist}} columns. Great. Obviously I do not use IE, but a lot of people do. If it does not work in IE, it does not work. So much for that.

My vague line of thought is that with the limitations of the wiki software, CSS and current browsers, and the range of devices, there is no way any page is always going to look good and be easy to navigate. There has to be a point where we say "It does not work for everyone, but this is the best compromise we are likely to get". A score of Good: 93%, poor 5%, bad 2% is better than Good: 40%, poor 59%, bad 1%, as long as the disabled are not part of the bad %.

There is a different page viewing paradigm for the touchscreen device, the not-so-smart phone with the up-down-left-right control, and the mouse-driven PC. My gut feel is that 30em is easily as narrow as we have to worry about, and that may be exaggerated. Nobody is trying to work a horizontal click-and-drag scroll bar on a smaller device than that. But we need facts. Meanwhile, for this particular set of templates, I am inclined to go with a three-column version and see what can be done to make it squish to as narrow a width as possible. And maybe experiment with a column-width approach on the assumption that hardly any small devices will use IE. Aymatth2 (talk) 03:38, 12 October 2012 (UTC)

I would say the unbolded collapsed format scores Good: 1%, Poor:95%, Bad: 4%. The 1% good are using screen readers. The 4% bad are mostly colorblind, but a few are trying to browse the web on 3x2cm displays. The rest are just looking at a great blob of unformatted text. They can see it all without horizontal scrolling, but it is tough to find what they want. This table version shrinks to fit most non-mobile displays, I would think, at about 650px width. Annoyingly, <a> elements get a nowrap style, and I can't see any way to override it. Not a major issue on this template though. Aymatth2 (talk) 19:30, 12 October 2012 (UTC)

@Aymatth2 - It's a well-known fact that IE is ... different. If you check the second box at the top of Template:Reflist (also WP:REFCOLS) you'll see that it states that IE up to IE9 doesn't support columns. It's not that we forgot to put in the CSS for columns on IE - we tried, and failed. There is much discussion on this at Template talk:Reflist and its archives]]. --Redrose64 (talk) 20:19, 12 October 2012 (UTC)

I did not mean to sound critical. I am sure if there was a way to make IE do columns, the CSS experts here would have implemented it long ago. It would be a big help in allowing for layouts that would adapt themselves to the available width. Too bad... Aymatth2 (talk) 20:37, 12 October 2012 (UTC)

Table columns, DIVs columns

Hi. While Template:Columns, Template:Multicol and Template:Col-begin (and more) are still using the unaccessible table-based columns, there are good alternatives available to us now. Columns made of DIVs are supported by all 5 major browsers, and are implemented trough templates and styles already. They are only waiting to be used. Template:Columns-list and Template:Div col are part of these.

We should fix the many templates and/or their inclusions accordingly. There seems to be a variety of templates for columns, and several look redundant to me. There is quite some cleanup to do.

We do not have a guideline about TABLE vs. DIV based columns, so I guess we should at least mention a good practice here. Dodoïste (talk) 19:08, 11 October 2012 (UTC)

wp may not have guidance on tables vs divs, but tables for layout are evil, as you, I, various others and anyone who has done serious web work knows. wp guidance is often pathetic or outright wrong; a consensus of those who don't know and those with an agenda.

Any columnar approach that fails to drop to one narrow column if the viewport is quite narrow is problematic. Columns done with css can do this, but it's unclear to me if these templates you're pointing at actually do. The test you made did not. And as I said; hlist needs further tweaks for mobile/small screens. Perhaps all the nowrap should fall away for those cases. Br'er Rabbit (talk) 19:53, 11 October 2012 (UTC)

Thanks for explaining how it should adapt itself to lower resolutions if done properly. I failed to understand this crucial part. I've found a few resources on the web, and will experiment with these columns further. Dodoïste (talk) 20:33, 11 October 2012 (UTC)

We've a crappy article on the concept: responsive web design. better:

The idea is popular and widespread. Cameron Adams did some of the early work (http://www.themaninblue.com/)

Br'er Rabbit (talk) 23:37, 11 October 2012 (UTC)

I know of this concept, and it's good. But I believe this is the kind of things WMF developers should do, not us. Anyway, I was thinking of another solution. See my sandbox User:Dodoïste/sandbox. This solution des not work in IE though. Dodoïste (talk) 21:18, 12 October 2012 (UTC)

Ah, my bad, that is exactly was they were discussing in the section above. And what was implemented in Reflist template. And IE 10 is still not released yet. Oh well, there is no helping it. Patience is of virtue, or so they say. Dodoïste (talk) 21:26, 12 October 2012 (UTC)

Newcastle Knights

some discussion on the talk page concerning the colouring used in Template:Newcastle Knights. Frietjes (talk) 15:38, 12 October 2012 (UTC)

International Standard

WCAG 2.0 is now recognised by the International Standards Organization, as ISO/IEC 40500:2012 (see [6]). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 23 October 2012 (UTC)

Thanks for the notification. This is some very good news. It's all new to me, so I don't quite measure the impact and importance it has or will have. But it sounds great. Dodoïste (talk) 18:11, 23 October 2012 (UTC)

Video and audio subtitles

Hi. Since we now have the possibility to include subtitles for audio and video, I have made a first update of this guideline. Good examples and guidelines about this feature will have to be done later on. Dodoïste (talk) 14:55, 4 November 2012 (UTC)

Supreme court opinions

any ideas on how to fix 2011 term opinions of the Supreme Court of the United States#2011 term opinions? I would try to fix it, but I'm not good with colour differentiation. Frietjes (talk) 23:36, 8 November 2012 (UTC)

Erk! A lot less green, a lot more white and some yellow, and it'd be a composition by Piet Mondrian. --Redrose64 (talk) 23:54, 8 November 2012 (UTC)

No idea. But it is unusable for average users, so it has to be redesigned from scratch. Perhaps we should split this table into several smaller ones? Dodoïste (talk) 00:13, 9 November 2012 (UTC)

maybe use border coloring and some abbreviated text in the middle of each cell? Frietjes (talk) 00:18, 9 November 2012 (UTC)

Each cell needs text in it. Start by setting up a key like "DO = Delivered the Court's opinion"; "JO = Joined the Court's opinion"; etc. Once we get a table that is readable without any use of colour, then we can think about adding colour to enhance the display for sighted readers as a bonus. Like Frietjes, I'd prefer a border to a background colour. Something like this:

JO

could be cooked up into a template to bury the html and would make a much more accessible table cell. --RexxS (talk) 03:41, 9 November 2012 (UTC)

Template:Storm colour

Could someone help me explain WP:CONTRAST at Template talk:Storm colour#Colors and accessibility guidelines? Thanks. Kaldari (talk) 02:40, 11 November 2012 (UTC)

I've replied there. And I made a few clarifications about the methodology used to test for color contrast compliance. Dodoïste (talk) 12:40, 11 November 2012 (UTC)

Template:Lithuania topics

if anyone cares to comment, there is some discussion concerning the random coloring using in Template:Lithuania topics. Frietjes (talk) 18:18, 19 November 2012 (UTC)

Hover Text

The Manual says: "Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text. Abbreviations are exempt from these requirements, so the template may be used to indicate the long form of a word."

Internal links provide redundant hover text which is exactly the same as the displayed text. Very often - in studying history, that I am unfamiliar with, for example, I have found myself reading a long article just to obtain an overview of what incident a link refers to. It would be possible to provide a phrase or short sentence as mouse over text that would improve the usability of Wikipedia.

According to my reading of Help:Wiki_markup this effect should be possible using transclusion. For example, at the end of the section en.wiki.x.io/World_war_II#Background there is a link to the Xi'an Incident. If instead of the text [[Xi'an Incident]] this was written as {{Xi'an Incident|Chinese Premier, Chiang Kai-shek, arrested 12-25 Dec 1936|Xi'an Incident|link=yes}} and a Template created with the name "Xi'an Incident" that contains only a link to the main Xi'an_Incident article, this should produce the effect required. However, I have tried this (without saving the new version of World_war_II) and it, in preview at least, does not seem to work. It just behaves like a standard link without any special mouse over text.

1. Do others feel, as I do, that using mouse over text in this way could significantly improve the usability of Wikipedia, without significantly compromising the principle of not requiring interaction to provide information so that page readers can interact correctly with the encyclopaedia, in the sense that no essential information is lost - what is provided is merely supplementary. I.e. if this proposal were adopted, anyone relying upon a page reader would have access to exactly the same amount of information that is available now, but those who can use mouse over text will gain added 'value'/usability from the encyclopaedia?

2. If so, should the manual of style be edited to permit it?

3. Is there anybody with more experience who can make it work?

4. Long term should consideration be given to providing a third parameter for a link to provide mouse over text so as to avoid the rather ugly two-stage referencing and the necessary proliferation of template pages?

Hedles (talk) 22:10, 4 December 2012 (UTC)

From the point-of-view of accessibility, providing extra information to some users and not to others does discriminate unfavourably against the latter group - in this case those unable to use a mouse. It is a pretty fundamental tenet of accessibility that all functionality should be available from the keyboard. I wouldn't be keen to see more effort being put to provide extra functionality just for the least disadvantaged users. It's not easy to change the default behaviour of hovering over links, which is determined by the browser itself (displaying the contents of the 'title' attribute on modern browsers).

Having said all that, have you tried enabling navigation popups from the Gadgets tab of your preferences? It may provide some of the functionality you're looking for. --RexxS (talk) 23:58, 4 December 2012 (UTC)

By the same logic, the very existence of Wikipedia discriminates against those who have no computer or cannot access the Internet, as well as against people who are both profoundly deaf and partially sighted. Wikipedia is here because the technology exists to be able to provide this information to any who are able to access it. There will always be some who are disadvantaged compared to others simply because the human race is not a collection of identical androids. Someone with a limited concentration span or (such as myself) with a very slow reading rate is disadvantaged, compared to someone with greater capability in these faculties. Surely, we should not be so worried that we might provide some 'unfair' advantage to those who might be considered "least disadvantaged", that we under-exploit the capability of the technology at our disposal. Rather we should aim at using every capability of the technology to provide the maximum benefit possible to everyone (of whatever ability) to make use of with all the powers they have available, while at the same time ensuring that, conscious of the special needs of those with some common disabilities, we do not design a system which cannot be accessed by them at all, when, by taking different design decisions, it could be made so available.

Electing not to provide any feature because it would not be available to some would result in no Wikipedia, since the only possible system that provides completely uniform benefit/advantage to all possible users is no system at all.

"Maximum access and utility to the maximum number of people" should be the maxim, rather than "identical access and utility to everyone". The former will lead to growth of use and participation, the latter to stagnation or decline.

Thanks for the advice about the Gadgets - I'll look into it. Hedles (talk) 11:58, 5 December 2012 (UTC)

Thanks, Rexx. Enabling navigation popups does almost exactly what I'm after. However it is dependent upon the author of the article writing in the first paragraph a good summary of the whole article and in a very few words. I am still of the opinion that a third parameter to the link could provide a better source for the pop-up text, because (1) it would not have to do two jobs with slightly different requirements and (2) it is almost certain that it would require considerably less processing to achieve the pop-up, which for people with older and, like me, frequently over-utilised computers (too many simultaneous processes) would often provide less delay. — Preceding unsigned comment added by Hedles (talk • contribs) 12:43, 5 December 2012 (UTC)

The fundamental idea you are trying to achieve is good in my opinion. Improving usability by offering a short definition of a subject - when the user encounter a notion he is not familiar with. The user may then decide that the definition is enough, and that he does not need to follow the link. Reading becomes a more fluid experience.

However, the solution you are suggesting have several flaws. The flaw of accessibility was mentioned: impaired users would also benefit from this feature, there is no reason to discriminate. Another flaw is to place yet another requirement on editors: write a summary of the article, for every link. Tremendous work, with complicated syntax... There are many simpler ways. The navigation popup gadget may not be perfect, but it is infinitely easier to improve the gadget than to manually change every link. Dodoïste (talk) 20:39, 5 December 2012 (UTC)

I agree with you that it is better to change the gadget than every internal link. This would involve a little extra work per article instead of a little extra work per link, which is obviously less work and therefore a better option, plus it automatically maintains referential integrity of the links with any update to the article. How would one go about developing the gadget?

I also agree that impaired users would also benefit from this feature. How would one go about providing this benefit to a user who relies upon a page reader, though?

I do not agree that it is discriminatory to provide a feature that cannot be accessed by certain users users because of the limitations imposed by the software they choose to/are limited to use in order to access Wikipedia. The discrimination is not made by Wikipedia but by the combination of their own disability and the software they use. If we were able to provide an open source reader that could somehow make use of the link gadget to provide access to the same 'additional' material, then the "discrimination" would only apply if they chose not to use that free software.

To argue that it is discriminatory and therefore ought not to be provided because not everyone can use it is like arguing that the visual indicators in railway trains and on platforms to show details about train journeys ought to be banned because the severely visually impaired cannot read them! That would be stupid. The answer is to develop some technological or other solutions that would permit the visually impaired to access the same information with equal facility. And - simply because there are vastly more people without severe visual impairment than with - the likelihood is that the solution for the visually impaired will follow on from the provision of the visual indicator for people with normal sight rather than being available at the same time or preceding it.

We can work on solutions to provide access to everyone, but that ought not to prevent us from providing additional facility that is not initially available to everyone. As aforesaid, such a rule would mean no Wikipedia at all, because it will never be possible for some severely handicapped people to access Wikipedia, no matter how wonderful the technology. Hedles (talk) 06:56, 23 December 2012 (UTC)

RfC: Section headings for horizontal navigation templates

Please comment on accessibility considerations, at Wikipedia talk:Categories, lists, and navigation templates#RfC: Section headings for horizontal navigation templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:03, 28 December 2012 (UTC)

Maps and colour blindness

I've asked a question at Wikipedia talk:WikiProject Maps#Colour-blind users, please join the discussion. --Nemo 18:54, 1 January 2013 (UTC)

Military ranks of Argentina

can someone convert the large image to text in Military ranks of Argentina? it may be easier to just start over from Gradi delle forze armate argentine. Frietjes (talk) 16:30, 15 January 2013 (UTC)

Fails?

A comment has been made on my FLC regarding one of the templates (here) at the bottom of the page and whether or not it fails WP:ACCESS because it has color. Though the template is used to separate the storms within the season, and not their actual intensities, the FLC director says it still fails. TropicalAnalystwx13 (talk) 23:36, 4 February 2013 (UTC)

I'm sure that this has come up before. The problem (if I recall correctly) is that the contrast on the TD and C5 squares (possibly others) wasn't very good. --Redrose64 (talk) 09:54, 5 February 2013 (UTC)

The colours are set in {{Storm colour}}. Since any accessibility issues with the colours in {{2010 Atlantic hurricane season buttons}} are not specific to Timeline of the 2010 Atlantic hurricane season, nor to any other articles that transclude that template, but could potentially affect any article using {{Storm colour}}, any discussion about accessibility issues with those colours should really be brought up at Template talk:Storm colour. --Redrose64 (talk) 22:55, 5 February 2013 (UTC)

Based on my own experiences of the reviewer is all he wants symbols added to the button bars to make them accessible.Jason Rees (talk) 22:27, 6 February 2013 (UTC)

additional parenthetical text for the Saffir–Simpson hurricane scale would not be a bad idea. Frietjes (talk) 23:27, 6 February 2013 (UTC)

My wife is color blind - She can see all of them but the one in between A B that links to Tropical Depression Two (2010).Moxy (talk) 23:35, 6 February 2013 (UTC)

the 5 should have the same contrast as the 2, unless you have clicked on one but not the other, causing a slightly different link colour. Frietjes (talk) 23:38, 6 February 2013 (UTC)

Confusion

Hello,

could someone explain why the tables in Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Avoiding_column_headers_in_the_middle_of_the_table don't have any row headers? And when are row headers exactly required? Regards.--Tomcat (7) 10:28, 10 February 2013 (UTC)

Sure, thanks for asking. Think of it like this. A table cell has no meaning alone. It is the table header associated with it that creates its meaning. In simple tables, having one type of table header (row or column header) is enough as the meaning is clear. A blind user will use table headers just like we do - provided they are correctly formatted. So when they are not necessary for us they are not necessary for blind users either.

In complex tables, you need both row and column headers in order to have meaningful data cells. Here is an example of a complex table. In this case, both headers are mandatory, for ourselves as well as for the blind.

I hope it helps. Cheers, Dodoïste (talk) 23:00, 15 February 2013 (UTC)

Logically, surely Other languages should follow Text?

(Moved it) LittleBen (talk) 13:21, 11 February 2013 (UTC)

Makes sense. Thanks! Graham87 14:22, 11 February 2013 (UTC)

Accessibility of new notifications system

I have raised a concern about the accessibility of the new Notifications feature for screen readers. It'd be best to make any substantial comments about it in the relevant bug report. Graham87 13:17, 4 May 2013 (UTC)

WP:NOSTRIKE and WP:REDACT

There is a conflict between the guideline WP:NOSTRIKE which "bans" strikethrough text, and WP:REDACT which encourages strikethrough (or < del>) text when redacting a talk page comment which has been replied to. Any ideas as to a resolution? — Arthur Rubin (talk) 19:47, 22 May 2013 (UTC)

There is an apparent conflict, yes: but I think that they are discussing two subtly different concepts. To me, WP:NOSTRIKE is concerned with text marked up with <s>...</s> <strike>...</strike> or ... as in ~~Text with the S element~~ ~~Text with the STRIKE element~~ or Text with the text-decoration:line-through; style Of these, STRIKE is marked as obsolete, with the recommendation to "use del instead if the element is marking an edit, otherwise use s instead". The S element is documented as "represents contents that are no longer accurate or no longer relevant". By contrast, WP:REDACT explicitly mentions the <del>...</del> element, which according to its documentation "represents a removal from the document": ~~Text with the DEL element~~. I may be wrong, but I believe that screen reader software will interpret the DEL element and describe it as deleted text, whereas the other forms are not given a special interpretation. --Redrose64 (talk) 20:32, 22 May 2013 (UTC)

I accept that as a possibility, but I'd like to hear what screen-readers do with < del>. That being said, I, not having read this section, have frequently readacted using < s> and , rather than < del> and < ins>, as the guidelines when I last checked, didn't specify. (Note to self: use CSS to change the appearance of < ins> from to .) — Arthur Rubin (talk) 20:43, 22 May 2013 (UTC)

I was also under the impression that <del>...</del> and <ins>...</ins> were the semantically accurate means of changing or removing text, so I would expect screen readers to announce them. I'd always recommend asking Graham87 for his experience as he has been using screen readers for many years and can give a user's perspective. --RexxS (talk) 21:04, 22 May 2013 (UTC)

The keyword in that part of the guideline is "articles". I know it's completely non-standard there, but I added that guideline because I found strikethrough used in, of all places, the Disability article (see my comment on its talk page). Perhaps that point should be removed if its causing confusion? For what it's worth neither the s, del or ins tags cause any change in how JAWS (and other screen readers) read text by default, but then again screen readers don't distinguish bold, underline or italics either unless they're asked to. I found the use of strikethrough in Wikipedia discussions a bit confusing when I first started here, but I got used to it. Graham87 01:41, 23 May 2013 (UTC)

Comment on strikethroughs in articles: You may see strikethroughs in one form or another in articles where there is a direct quotation or where it is being used as an example. While I don't have any specific examples, I will give two hypotheticals: 1) If there is an article about a famous document that was published with strikethoughs in it, the article will likely have a photo of the document and may have a partial or complete transcript, including the redacted text surrounded by <strike></strike> or something similar, and 2) Articles about HTML markup languages may include examples, and these examples may include <strike> and similar mark-ups. These should be considered as exceptions (WP:IAR) to any guidelines prohibiting their use in articles, and #2 should be an exception to any "don't use <strike>" guideline. davidwr/(talk)/(contribs)/(e-mail) 17:07, 25 May 2013 (UTC)

Suggestion - create templates for {{s}}, {{deltext}} ({{del}} exists) and {{ins}} that, for now, would translate to <s>{{{1}}}</s>, <del>{{{1}}}</del>, and <ins>{{{1}}}</ins>. As screen-reader standards change, the implementation of the templates can change. On this note, if we don't already have a "meta" template called "htmlencapsulate" or whatever that becomes <{{{1}}}>{{{2}}}</{{{1}}}> we probably should. davidwr/(talk)/(contribs)/(e-mail) 17:18, 25 May 2013 (UTC)

I don't see the point of that, to be honest, but I've never been a fan of small templates that don't do very much like {{Spaces}}. I don't think screen reader standards will change significantly without a strong change in the HTML specification. Graham87 06:44, 26 May 2013 (UTC)

And yes, the exceptions that you laid out where strikeout *can* be used in articles sound fine to me. Graham87 07:01, 26 May 2013 (UTC)

including talk page discussions

WTF? Why did this get entered without discussion? Walter Görlitz (talk) 22:08, 21 May 2013 (UTC)

http://en.wiki.x.io/w/index.php?title=Wikipedia_talk:Talk_page_guidelines&action=submit Walter Görlitz (talk) 22:09, 21 May 2013 (UTC)

Stop forum shopping. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:12, 21 May 2013 (UTC)

I am not forum shopping.

I am asking why it was added here without discussion.

When you pointed out the wording, I saw it immediately as odd.

If you think it's forum shopping, take it up at AN/I. Walter Görlitz (talk) 23:29, 21 May 2013 (UTC)

Wikimedia software uses definition lists <dl><dt>...</dt></dl> to indent discussions on talk pages

So all your comments on talk pages are lists.

WP:LISTGAP applies to your indented comments just the same as any other list.

When you leave a blank line before your indented comment, as you did above, you cause the Wikimedia software to close one list and begin a new one.

A screen reader will hear something like "... definition list one item, definition, Stop forum shopping. ... 21 May 2013 (UTC), end definition, end list, end definition, end list" - "definition list one item, definition, definition list one item, definition, definition list one item, definition, I am not forum shopping ..."

That's if you insert the blank line between a second level indent and a third level. If you were to insert it between (say) an eighth level indent and a ninth, then you have eight lots of closing and nine lots of opening to inflict on the visually impaired reader.

It would be best not to ignore the advice given in WP:LISTGAP. It has a big impact on accessibility. --RexxS (talk) 23:49, 21 May 2013 (UTC)

As far as I can tell, JAWS doesn't read out the definition lists in Wikipedia discussions unless there's another list in the mix (whether it be ordered or unordered). However, NVDA always reads them out. Therefore it's still a good idea to include the talk page exception here. Graham87 03:04, 22 May 2013 (UTC)

Thanks. JAWS is one of the two readers that have used for accessibility testing.

So what I'm reading is that not ALL readers have this problem that is created by the way that Wikipedia represents talk page comments. So why are we punishing editors for this? Why don't we fix the way talk page comments are displayed, or at least saved. Walter Görlitz (talk) 04:51, 22 May 2013 (UTC)

We are not punishing editors; we are assisting readers. We don't have it in our gift to change MediaWiki in the short term; a long term replacement for talk pages is already in hand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:10, 22 May 2013 (UTC)

Why is there an edit war over this? The debate above is very clear that LISTGAP applies to discussions. Why would anyone want to prevent that information being clearly stated in the guidance? --RexxS (talk) 13:55, 22 May 2013 (UTC)

A bit of history. The shortcut WP:LISTGAP was created by myself, and added with this edit which I admit was WP:BOLD. It went unchallenged; and indeed I believe that my case was strengthened by this edit over 16 months later. Between those two, the only change to the relevant section was these two edits. If we move forward to this point, almost 21 months after I created the shortcut, and just over one month ago, we see that the relevant text hadn't changed since Dodoïste's pair of edits. Then we got this edit which heavily distorted the text, as I pointed out at User talk:Thomasmeeks#Gaps in lists. It is since then - and probably as a consequence of it - that the present dispute has arisen. What if we were to revert that section to the point immediately before?

Some terminology may be necessary. A "definition list" is the term which was used for the DL element until HTML 4.01; in HTML5 it is now known as an association list. Regardless of the terminology, that is the structure that is generated when we use colons to indent (as I did at the start of this paragraph); and the use of a blank line in the middle of such a list forces all open DL elements to be closed, and a fresh set to be opened. This is exactly the same outcome as a blank line being added into a bulleted list, and the LISTGAP shortcut was intended to embrace both of those as well as the ordered list, where the effect of a blank line is much more obvious to the sighted person: the item numbering resets to 1. --Redrose64 (talk) 14:28, 22 May 2013 (UTC)

@RexxS - Because it goes against one editors personal preference. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 22 May 2013 (UTC)

No Andy, it's not that I don't like it. It's that we shouldn't force a system on any editor just because the technology isn't kind. I don't mind complying for the sake of a few bad screen readers or because the talk page replacement (which is good to know about) isn't in place yet, but your attitude has been as much to blame as mine has been. Walter Görlitz (talk) 19:17, 22 May 2013 (UTC)

It is very clear that WP:LISTGAP does not apply to discussions, even with Andy's latest clarification. That being said, I think it's generally a good guideline, but there can still be good reasons for blank lines (or ) in discussions. (In most cases, the blank line should be appropriately indented, which seems to solve both problems.) — Arthur Rubin (talk) 19:48, 22 May 2013 (UTC)

It is very clear that WP:LISTGAP does apply to discussions. If you wish to leave a visible gap in the middle of a comment, for some reason, you can use :::::First para Second para. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:03, 22 May 2013 (UTC)

No Arthur, LISTGAP explains that leaving a blank line in any list causes the mediawiki software to close one list and start another. Do you deny that? We use colons to emulate (poorly) indented "threaded" discussion on talk pages. Do you deny that? Those colons produce "definition lists" (i.e. the <dl><dd> ... </dd></dl> structure). Do you deny that? The effect is that leaving a blank line between indented comments on a talk page causes the mediawiki software to close one list and start another. Do you deny that? So please tell me in what sense you think "It is very clear that WP:LISTGAP does not apply to discussions". --RexxS (talk) 20:14, 22 May 2013 (UTC)

A few comments, and maybe we can get back to sensible discussions:

Wikipedia guidelines, unless otherwise specified, refer to the intent of the text, rather than the Wikipedia implementation. Hence including Wikithreaded text is a change. (We can discuss misuse of ";" as a section heading later; I don't think it's here in this guideline.)
I don't doubt that you get consensus for the change to include threaded text within WP:LISTGAP, although it will need to have more exceptions. The guideline should read something like "no blank lines unless there is a good reason." This means that a simple gap between comments should be fixed, but more complicated subthreads may be indicated by blank lines if appropriate.

So, let's seek consensus for the change, and solve the problem is an appropriate manner. — Arthur Rubin (talk) 20:53, 22 May 2013 (UTC)

I did an experiment at User:Guy Macon/sandbox with adding lines between comments. Adding four linefeeds added 150 bytes to the HTML source. Compare this with the Wikipedia globe (19,670 bytes) the Javascript (7,523 bytes) or the wikimedia button at the bottom of the page (2,426 bytes). I also did some extensive research, and I cannot find any evidence that any screen reader released later than 2005 has a problem with the HTML that Wikipedia sends when there are added lines between comments but not when the lines are removed. Yes, it does add a bit of extra code (about 40 bytes per added line) but it appears that when popular websites started using definition lists to format text, the screenreaders started outputting just the text without reading the tags aloud. I have not personally confirmed this because screenreaders are fairly costly. --Guy Macon (talk) 01:04, 23 May 2013 (UTC)

As I said above, NVDA reads the definition lists in Wikipedia discussions. I, personally, use JAWS almost exclusively (which usually doesn't have this problem as I also said above), and I only use NVDA as a backup when JAWS crashes. But NVDA is getting better and better, and a growing number of blind people, especially beginners, use it exclusively. All screen readers do read out complete definition lists (with semicolons and colons), like at Wikipedia:Glossary. I'm starting to wonder if enforcing the talk page rule would be more trouble than it's worth? Bad unordered HTML lists (with "*") are more of a problem. Graham87 01:54, 23 May 2013 (UTC)

Given the above discussion, I propose that we remove This addition to the page until such time as we arrive at a consensus for including it. While saying "Note that talk page discussions are formatted using HTML definition list markup." is technically correct, it strongly implies that our long-established accessibility rules for lists should be applied to all talk page discussions. I think we have established that that would be a controversial change, and thus the editor or editors who added it should seek consensus for the disputed change rather than slipping it in during an edit war. --Guy Macon (talk) 07:39, 25 May 2013 (UTC)

No thanks. Our long established accessibility guidelines apply to talk pages just as much as articles. Your allegation of "slipping in" is asinine. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:01, 25 May 2013 (UTC)

Please be WP:CIVIL. Applying the rules for lists to all talk page discussions is a major policy change. I am going to wait to see what the other editors say (it could very well be that you already have consensus for the change), but if it remains clear that this is disputed, WP:TALKDONTREVERT and WP:BRD apply. --Guy Macon (talk) 08:18, 25 May 2013 (UTC)

Unlike your asinine allegation of "slipping in", my comment as perfectly civil. Your claim that this is a "major policy change" is equally bogus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:24, 25 May 2013 (UTC)

Nobody is calling for the "enforcing of a rule". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:01, 25 May 2013 (UTC)

Add the text (or keep it there, if it's there at present, since it keeps getting added and removed). As the creator of the shortcut in question, my intent was that it would embrace talk page discussions. My regret is that it wasn't already explicit two years ago. --Redrose64 (talk) 15:21, 25 May 2013 (UTC)

Policy change or Clarification?

Guy, why did you do this without consensus? --Redrose64 (talk) 11:21, 27 May 2013 (UTC)

It was added during the recent edit war. It changes Wikipedia policy by attempting to apply the rules for lists to talk pages. There is no consensus to make this change in Wikipedia policy. I am aware that some who want to add this say it is not a change of policy, but I am willing to defend my assertion that it is at WP:ANI. I encouraged those who want this change in policy added to seek consensus through discussion and possibly an RfC, but there appears to be little interest in doing that if your desired change of policy can be slipped in under the radar by doing nothing. You and others who disagree with me now have three choices. You can revert, and I will take it to ANI for trying to change Wikipedia policy through edit warring. You can take it to ANI and report me for allegedly going against an imaginary consensus for the policy change, or you can seek a consensus through discussion and/or an RfC. I will, of course, not oppose the change if there is a consensus for the change. --Guy Macon (talk) 11:42, 27 May 2013 (UTC)

We are not attempting to change policy. We are trying to clarify existing policy, which was not to insert blank lines into definition lists. May I remind you of your edit summary here; it seems to me that it is you who is going against WP:TALKDONTREVERT and WP:BRD. --Redrose64 (talk) 13:10, 27 May 2013 (UTC)

Guy, you may not unilaterally decide what is part of this guideline. There is no "change of policy" involved in making editors aware that "... talk page discussions are formatted using HTML definition list markup." Stop edit-warring and address the points that have been made. The issue exists as Graham has pointed out to you, regardless of whether you own experiments find the same problem. Graham is a long-time editor of Wikipedia and a very well respected administrator. Being blind, he has far more experience of using screen readers that either of us and if he says the issue exists, then it exists. It should be obvious that producing html that closes, for example, 12 levels of nested list and then opens 13 new nested levels will cause problems for some assistive technology and I simply don't believe that you can check every case - nor can you know how many disadvantaged readers your intransigence is affecting. It's time you stepped away from trying to force this debate by edit-warring. If you feel so strongly about this, let's call for an RfC. --RexxS (talk) 00:20, 28 May 2013 (UTC)

Let's review, shall we?

Fact: The only screen readers that you or anyone else claim to have this problem are JAWS and NVDA. If you want me to research any other screen readers, let me know. BTW, statistics on screen reader use are here.

Fact: The only source you have provided is some original research by Graham87 (who you keep misidentifying as "Graham", thus making it difficult to check your claims). You have provided no other references that claim this is a problem.

Fact: Graham87 says that JAWS does not have a problem, but that "NVDA reads the definition lists in Wikipedia discussions".[7]

Fact: I provided a citation[8] that says "NVDA just reads the items without announcing that it's a list or that the terms and definitions have any relation. The content is just read in a linear fashion." Need I remind you that citations to reliable sources trump original research by Wikipedia editors?

As an aside, I suspect that the reason that Graham87 reports a problem is that he is using an older version of NVDA -- he says "I, personally, use JAWS almost exclusively (which usually doesn't have this problem as I also said above), and I only use NVDA as a backup when JAWS crashes".[9]

Conclusion: You have yet to provide any evidence at all that separating talk page comments by hitting the enter key twice is a problem. As for your latest revert's edit summary ("this is a fact, and should be noted")[10] and subsequent talk page edit summary ("no "change of policy" involved in making editors aware"),[11], when you change a page that says "Do not separate list items, including items in a definition list" by adding "Note that talk page discussions are formatted using HTML definition list markup", and you make this change in the middle of a heated edit war about whether Wikipedia should forbid separating talk page comments,[Note] you are clearly attempting to make the page say that talk page comments are lists and that you cannot separate talk page comments -- a policy that was not there before your change. You are doing this without any consensus that our policy should be changed to forbid separating talk page comments.

Note: I did not participate in the above-mentioned edit war. My only edit followed BRD, being the first Revert[12] of a Bold edit[13] that expanded our "do not separate list items" policy by adding "including talk page discussions" -- the same policy change you are attempting to force into this page with your latest revert. This should have gone to talk page Discussion after the Bold addition and my Rrevert of same. See WP:BRD and WP:TALKDONTREVERT.

I am not the only person who noticed that you were trying to make a policy change. See edit summaries by administrator Bbb23 ("unnecessary change - you'll need to gain a consensus for it)[14] and administrator Arthur Rubin ("It's a policy _change_, not a "clarification")[15] I might also mention that the wording you are supposedly "clarifying" by expanding it from lists to lists and talk page comments, was itself "clarified" two weeks ago from "bulleted vertical lists" to "lists."[16] The language about screen readers that has been so badly morphed over the last two weeks was added in 2010.[17]

RexxS, I really must insist that you get consensus before making policy changes. Please self-revert your latest edit until such time as there is a consensus to change the policy. --Guy Macon (talk) 06:36, 28 May 2013 (UTC)

Fact: Contrary to the above claim (beginning "Note: I did not participate in the above-mentioned edit war"), Guy Macon did revert more than once: [18], [19]. --Redrose64 (talk) 10:48, 28 May 2013 (UTC)

You appear to be confused. Perhaps a timeline will help you.

08:05, 22 May 2013: My first edit.[20] (Following WP:BRD: BR.)

09:07, 22 May 2013: Start of edit war.[21] (reverting instead of discussing: BRR.)

20:00, 22 May 2013: End of edit war.[22]

20:00, 23 May 2013: End of protection.

11:01, 27 May 2013: My second edit.[23]

Note that nothing in Wikipedia's edit war policy says that once someone else starts an edit war that I do not participate in, I am forever banned from reverting new attempts to change Wikipedia policy without consensus. I waited over three days for you or anyone else to attempt to form a consensus for your desired policy change, then concluded that you would never attempt to form a consensus, having already inserted your new policy without consensus and shown your willingness to keep it there with reverts, knowing that I will not edit war.

Still waiting for that evidence that anyone is affected by this... --Guy Macon (talk) 11:38, 28 May 2013 (UTC)

You started the edit war, by making the first revert. You did not contribute on this talk page until 01:04, 23 May 2013 - 17 hours later. Expiry of protection does not wipe the slate and give license to restart an edit war. I am still waiting for evidence that talk page discussions indented using colons are not lists. --Redrose64 (talk) 12:13, 28 May 2013 (UTC)

Evasion noted. Let me know if you ever decide to provide some actual evidence backing up your claims. As far as I can tell, no screen reader from 2005 onward has the slightest problem reading Wikipedia talk pages no matter how we separate posts.

Yes. I made the first revert. Also known as the R in WP:BRD. If you think I am edit warring, report it at Wikipedia:Administrators' noticeboard/Edit warring. Your continued false accusations are inappropriate behavior. Please stop. --Guy Macon (talk) 13:01, 28 May 2013 (UTC)

This is a guideline, not a policy. "Misidentifying" me as Graham makes as much sense as misidentifying you as Guy. I've just updated to the latest version of NVDA (2013.1) and it still reads definition lists in the way I described above; I think I was using NVDA 2012.3 before. As for your source, either NVDA's behavior has changed since it was written or the user simply missed NVDA's notifications about the list. I think the latter is more likely because (a) that author is sighted and does not habitually use screen readers, (b) it's easy to miss because NVDA reads properly formatted lists very subtly (it just mentions there's a list and then reads the items, but there'd be no way to miss announcements of five or more levels of definition lists as can happen in Wikipedia discussions), and (c) I don't recall any major changes to the way NVDA reads websites in the past two years or so. Graham87 14:52, 28 May 2013 (UTC)

Thank you for the clarification. The above is the first credible evidence I have seen that this is a problem for anyone. Given this new information, I am going to do what our edit warriors should have done long ago, which is to write up a request for comments and let the community decide whether to change our policy so as to forbid extra lines in talk page comments. I actually considered doing so when I first saw the attempt to set policy on this without seeking consensus, but would have meant proposing something but not being able to provide any credible reason for it.

As for WP:BRD being a guideline and not a policy, WP:EDITCONSENSUS is a policy, and BRD is based upon it. The policy and the essay say the same thing, which is that my reverting a change of policy with an explanatory edit summary was proper behavior, and that reverting me rather than discussing the issue was not. As an aside, I just noticed that WP:EDITCONSENSUS has an image with no alt text. I will fix that as soon as I finish here. --Guy Macon (talk) 20:00, 28 May 2013 (UTC)

I read Graham87's post "This is a guideline, not a policy" as referring to MOS:ACCESS, not WP:BRD. --Redrose64 (talk) 20:41, 28 May 2013 (UTC)

Good point. I may have misread that. If so, the relevant links are WP:POLICIES, WP:GUIDES, and WP:PGE (Especially Misconception #5 at WP:PGE). Needless to say, consensus is required to change guidelines as well as policies. This includes any "clarification" where you think the old text implied what your change makes explicit, but other editors (in this case me and two different administrators) disagree and think that your clarification was not implied in the previous text. As I have said several times, I don't oppose the change, just the attempt to push it into the page with reverts instead of seeking consensus, and I will be glad to take the appropriate steps to determine what the consensus is -- I just needed some small scrap of evidence that this affects anyone. --Guy Macon (talk) 21:17, 28 May 2013 (UTC)

Yes, let's do follow POLICIES. I particularly support following the WP:PGBOLD in this instance. Note the absence of any requirement to have an RFC in it. WhatamIdoing (talk) 22:16, 28 May 2013 (UTC)

I have requested a clarification: Wikipedia talk:Policies and guidelines#WP:PGBOLD. --Guy Macon (talk) 23:55, 28 May 2013 (UTC)

Yes, I was only referring to the accessibility guideline in my message above. Graham87 02:49, 29 May 2013 (UTC)

Abstract/Accessibility:

It's not a policy page, it's a Manual of Style page.
This addition is not a "rule" to be followed, it's a description of the way the software works.
It can be verified by looking at the source code of any usage. (See the <dl> and <dd> code, as explained at HTML element#Lists)
It can be seen to break, even more easily, by adding a blank line between (#) numbered list items.
It's been known as being problematic ever since it was conceived. It's been an official bug (bugzilla:4521) since 2006.
I mentioned it 3 weeks ago, in an unrelated discussion at WP:VPR!

Specific/Practical:

Formatting a comment like this, as you did, leads to a increase in visibility for the comments of the person making the double-spaced comments. If everyone did this, it would greatly increase the size of talkpages. It's counter to the standard/traditional/accepted/normal way of formatting, that everyone else uses.

We similarly prefer that people don't use excessive bolding or ALLCAPS in their talkpage messages, because again, if everyone did this, there would be a sea of emphasis (because EVERYONE thinks their own comments are important, and deserve recognition/reading). Every page would look like it had measles! (Also because bold and allcaps are commonly thought of as the textual equivalent of shouting).

To put it another way: Adding more spaces between your own paragraphs, is imposing your individual paragraph-leading preference on everyone else. Please don't! If you wish to change (slightly increase) the default paragraph-leading for everyone, the best place to do it is probably WP:VPT with a request for a change to the default <dl> and <dd> CSS.

Hope that helps. –Quiddity (talk) 04:43, 29 May 2013 (UTC)

Just a minor clarification; that oddly-spaced post was a bit of an experiment/demonstration (adding adds too much space and is distracting and ugly), not the issue we have been discussing. The issue we have been debating looks like this:

This comment is directly under the comment above it, and would be allowed under the new policy.

This comment has an extra line feed above it, and would be forbidden under the new policy.

This is another comment that would be allowed.

This is another with forbidden spacing.

and here I am back at the proper indent level. As you can see, the real difference is in the edit window. The difference in the talk page after you hit save is minor. --Guy Macon (talk) 05:30, 29 May 2013 (UTC)

Understood. (Albeit a very confusingly timed test...)

And I recognize that when we're not indenting, we have to double-space our paragraphs in order to have proper break between them. (As per standard article text formatting)

However, it is a "best practice", a preferred style, a wiki-wide standard, to use single-spacing between indents/paragraphs, once indenting has started. The same goes for bullet-points/numbered-items (unordered/ordered lists).

To be clear: Please stop using the word "policy" here! This page is not, and has never been, a WP:POLICY - that word has a very specific meaning on Wikipedia. This page is a Guideline, a subpage of the general Manual of Style guidelines. Referring to it as "policy" will confuse the issue, and make everyone think you've misunderstood this fundamental distinction, and perhaps other aspects.

Have hope! WP:Flow will solve all of this. A Usertalk namespace test, is coming soon!

Until then, it would be helpful/pragmatic if you could follow the standard that everyone else tries to follow, most of the time. Thanks. –Quiddity (talk) 07:29, 29 May 2013 (UTC)

The reason I used the term "policy" is not because I don't know the difference between guidelines and policies, but because the act of Pigsonthewing/Andy's edits ordering people to space as prescribed by his controversial recent addition to this guideline and reverting them when they fail to comply is, in essence, an act of transmogrifying the guideline into a de-facto policy. This would not have been an issue had he merely recommended following the guideline, as you did above. Nonetheless, I will avoid the term as being confusing. --Guy Macon (talk) 13:32, 29 May 2013 (UTC)

Oh, go on then, Do cite me "ordering people to space as prescribed". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 29 May 2013 (UTC)

Cite, as requested. (Note edit summary). Also see: Negationism. --Guy Macon (talk) 14:37, 29 May 2013 (UTC)

The edit summary was "rv per WP:LISTGAP, which says "including items in a definition list (a list made with leading semicolons and colons - including talk page discussions)")", which in no way whatsoever constitutes an order. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:43, 29 May 2013 (UTC)

Riiiiight. Reverting someone and quoting a guideline in the edit summary "in no way whatsoever constitutes an order" to follow that guideline. Like I said, see: Negationism: "The illegitimate distortion of the historical record such that certain events appear in a more favorable light". I am going to stop responding to you now per WP:IAD. Your denial of your own previous behavior is becoming boring and predictable, and it is clear that you will never take personal responsibility for your own actions. Feel free to make whatever further accusations you wish; I will not dignify them with a response, and at this point nobody else is listening to you. --Guy Macon (talk) 15:02, 29 May 2013 (UTC)

Guy, thank you for the link to Snook's "Definition Lists versus Tables". I found it particularly helpful in validating the approach we have been taking with tables (at WP:DTT), although not particularly enlightening about definition lists. Reading through the comments more or less proves my point: Snook was doing a one-off test; I simply wouldn't put that sort of test up against Graham's experience of many years in using screen readers. It's interesting on reading the comments on Snook's page that the behaviour of NVDA has been reported in the past to depend on the browser used and whether it is running inside a virtual machine (see http://community.nvda-project.org/ticket/263 and https://bugzilla.mozilla.org/show_bug.cgi?id=532338). I'm beginning to suspect that different systems are quite capable of producing different results with NVDA. I think that is a reason why we should take a line of "do least harm". I can't see any way of estimating the number of readers affected by LISTGAP inside discussions, but it seems that I expect it to be a far greater number than you do. Nevertheless, I weigh that against the minor nuisance of poor readability of wikitext in "threaded" discussions and conclude that I want to protect disadvantaged readers over sighted editors. So perhaps you can see why I am so insistent that we ought to be providing guidance to editors, many of whom don't know what the effect of LISTGAP could be on some screen readers when reading talk page discussions. --RexxS (talk) 09:10, 29 May 2013 (UTC)

I'm afraid I have to side with Guy Macon against the blind readers. The very start of WP:POLICY says "There is no need to read any policy or guideline pages to start editing. ". Going around editing peoples contributions on talk pages or rebuking them because of this will simply turn off new contributors. If there is to be a solution which suits blind people better it has to be in a way that does mean new contributors are told off or pointed at funny guidelines or have their contributions edited. People don't like having their contributions of talk pages edited. The right place for a solution is Village pump (technical). As to all this not being a change, it is sophistry saying that because an implementation is in the form of a list therefore the original is. They are not logically linked. Dmcq (talk) 09:54, 29 May 2013 (UTC)

Are you familiar with the concept of a straw man argument? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 29 May 2013 (UTC)

Please address the issues rather than engaging in personal attacks. If you have a point to make then try making it clearly. Dmcq (talk) 10:10, 29 May 2013 (UTC)

Asking me not to engage in personal attacks is, ironically (or perhaps deliberately?) also a straw man argument. Such use of straw men is the issue which I addressed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:40, 29 May 2013 (UTC)

Just address the issue in a straightforward way in your answer instead of directing me to search through things your wrote. There is no other mention of straw man on this page. If you want me to read something specific then put in a reference to it. Dmcq (talk) 10:52, 29 May 2013 (UTC)

When accusing someone of a fallacy of argument, I believe it’s customary to point out where that fallacy was committed. Though I disagree with Dmcq’s point, personally, I’m not sure where you think he committed such a fallacy. —Frungi (talk) 21:38, 29 May 2013 (UTC)

On the other hand, it would be appropriate for Dmcq to explain how a newbie could be affected by this. Sure, they'll get it wrong, but it can be easily fixed and nobody's going to get blocked for it. I've also never seen any new editor complain about minor or technical fixes to their comments. So why not tell people like Guy (the person who is actually complaining, and whose >13,000 edits means that he's not a new contributor, and whose experience level is far more typical of the people reading this page than "new contributors") that this bug exists and that a no-stray-lines approach is preferable? WhatamIdoing (talk) 22:33, 29 May 2013 (UTC)

I thought i had explained quite clearly but I will try and make my explanation simpler and more explicit.

Newbie comes along. Tries to do the simplest thing a new person can do which is to post something onto a talk page. Advanced editor here comes along and reformats their post saying that the reason is their contribution is a list item whereas it looks nothing like that to them and that it is a list item because of the way Wikipedia implements indenting. Exit newbie having decided Wikipedia is no place for them if they can't even put in a simple comment having taken the trouble to try and copy what other people have done.

A new person should encounter an environment that makes a bit of sense and which doesn't require reading all the guidelines before contributing. That is my reading of the intent in WP:POLICY of " There is no need to read any policy or guideline pages to start editing. " Dmcq (talk) 12:30, 30 May 2013 (UTC)

And by the way people explicitly put in blank lines for readability and to delineate text sometimes as the paragraphs are rather close together. Without some blank lines some things can appear line a wall of text and separate contributions are squashed together. Dmcq (talk) 12:36, 30 May 2013 (UTC)

There are forms of dyslexia where such a "wall of text" is reported to start swimming in front of the reader's eyes, and whitespace is reported to help a lot. It would be interesting if someone insisted on always double spacing to accommodate dyslexics and all of those who keep claiming that there is no requirement to demonstrate that a single blind person is actually inconvenienced suddenly started insisting on evidence of a single dyslexic who is actually inconvenienced... --Guy Macon (talk) 00:22, 1 June 2013 (UTC)

In Guy's "example" above, I can easily see the difference. But Guy, you're missing the point: the real difference for you is in the edit window. The read difference for people who are using screen readers is not in the edit window, but on the plain talk page. You see no particular difference. Someone like Graham is going to have to listen to an announcement about the presence of a new list for each and every one of these blank lines. Knowingly triggering that bug doesn't sound very kind to me, so why not tell people how they can avoid it? WhatamIdoing (talk) 22:33, 29 May 2013 (UTC)

That is a problem with the rendering between the editors intentions and what the blind person gets. So it is a technical problem and should be dealt with at WP:VPT in the first instance. Only if a technical solution not possible without some effort should things be done which cause the underlying representation to become visible and of concern to editors in general. We have had problems with people at the maths project trying to make maths better with temporary tricks. It has been rejected as a bad idea. This sort of messing around should be avoided if at all ppossible. Dmcq (talk) 12:43, 30 May 2013 (UTC)

Nonesense. The software works correctly if used as specified (and as advised in the guideline in question). There is only aprblem when editors use the markup incorrectly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:55, 30 May 2013 (UTC)

The software is not working correctly as it is not using the html tags for their intended purpose. See the lead of our article HTML element "HTML elements represent semantics, or meaning" Dmcq (talk) 13:01, 30 May 2013 (UTC)

Feel free to raise a Bugzilla ticket. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:03, 30 May 2013 (UTC)

Why would I do it? It requires someone with a real interest in the outcome and I'm not blind. I'm simply interested in stopping unnecessary trouble for new editors. Show there is no reasonable technical fix before expecting any support from me for hassling new editors. Dmcq (talk) 13:19, 30 May 2013 (UTC)

I didn't expect that you would; though as I said you would be welcome to. Since you have now made clear that you have no real interest in raising a ticket for what only you appear to consider to be a bug, we can consider the matter closed. The "technical fix" is to use the Wiki markup as specified; and your "hassling new editors" is another straw-man Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:51, 30 May 2013 (UTC)

Dmcq 13:01: I had to re-read this to make sure I wasn't mistaken. I'm still not sure if I am. You seem to be saying that the software is at fault by failing to divine what we mean when we misuse markup. —Frungi (talk) 14:12, 30 May 2013 (UTC)

I do not wish to impute any fault on the people who wrote the software if it was misused compared to what they wrote it for. However I am a bit concerned that a bug about this has been outstanding for 7 years with no discernable action. I am not too worried about the precise mechanisms behind the scenes provided it leaves a semantically reasonable model for editors rather than they be too concerned about implementation details. Dmcq (talk) 15:31, 30 May 2013 (UTC)

I don't think it is semantically reasonable to present threaded discussions as definition lists. But that's what we do here, and discouraging the practice of using blank lines is making the best of a non-ideal situation. —Frungi (talk) 15:51, 30 May 2013 (UTC)

'Best of a non-ideal situation' is one of a number of things that is under dispute. Whether it is worth causing problems and deterring new editors for the gain in accessibility. Dmcq (talk) 17:44, 30 May 2013 (UTC)

The phrase "making the best of a non-ideal situation" has a tendency to conflate two separate issues: "Is this a big enough problem to be worth addressing?" and "Is this proposed solution the best way to address this?" The classic example used to illustrate this is "thousands of people die in auto accidents every year. Redesigning all automobiles to have a top speed of 5 mph is making the best of a non-ideal situation." Yes, those deaths are undesirable. Yes, the 5 mph limit will greatly reduce the death rate -- far more than, say, airbags, guard rails, or reducing drunk driving. The problem is that this only considers the upside of the 5 mph limit (fewer deaths) without considering the downside (it takes ten times as long to get to work, and we need to build enough roads to accommodate ten times as many cars -- think about it). It also ignores other possible solutions, such as self-driving cars. That is essentially what is being done with the argument that the only possible solution to a screen reader issue is to change the behavior of thousands and thousands of Wikipedia editors. What about changing the way we change wikimarkup into HTML? What about the Wikimedia Foundation devoting some of our resources to making it so that the open-source NVDA screen reader is immune to the problem? This is why making undiscussed changes to guidelines and keeping them in in a clear violation of WP:BRD is so pernicious; by bypassing the discussion, we never get to even consider any other solution. --Guy Macon (talk) 20:35, 30 May 2013 (UTC)

I actually wasn’t aware that that phrase was a thing. Honestly, I think your point is lost in the ludicrousness of your example, unless blank lines in a Talk page discussion serve some crucial function of which I am unaware. It seems utterly trivial and completely reasonable to me to simply not use them or to remove them once you’re done typing, and it aids in accessibility, which is a Good Thing. I agree that more substantial changes are necessary (and have been for several years), and word is that Flow will be replacing our current Talk pages with something that’s actually designed for discussions.

No one is stopping alternative solutions from being discussed, so if anyone has any suggestions that are as simple to implement as not pressing enter twice, or simple enough that it would be worthwhile to do rather than just wait for Flow, please share. If not, discouraging blank lines is a small thing we can do in the interim.

Correct me if I’m wrong, but it sounds like you’re objecting to the principle of how the concept was introduced more than to the concept itself. Of course BRD should not have been violated, but the “change” simply described reality. It is undeniable that semicolons and colons in wiki markup create HTML definition/description/association lists (<dl>...</dl>). It is undeniable that this occurs on Talk pages. The guideline had already described the adverse effect of blank lines within lists. All the change did was bring attention to the fact that the effect occurs on Talk pages as well. Now, if the problem is with an editor’s conduct regarding that fact, and it wasn’t as simple as deleting blank lines from Talk threads, that’s another matter entirely, just as if I were yelling at my fellow editors for using the wrong number of colons—the problem is the editor, not the guideline. —Frungi (talk) 02:14, 31 May 2013 (UTC)

If, as you say, you believe that "BRD should not have been violated", then you should have no objection to the page being restored to the state it was in before the bold edit, which of course the exact same state it was in after the bold edit followed by my revert. If, on the other hand, you insist that the bold change remain in the article, then you must not believe that "BRD should not have been violated", and prefer the current state of the article, which came about by WP:BRRD, not WP:BRD. --Guy Macon (talk) 06:27, 31 May 2013 (UTC)

I’ve never reverted its removal, and I’ve never supported the reversion of its removal, though I maintain that it is not a substantive change to a policy or guideline, so I would contest a removal on those grounds. But I happen to support the bold change, since it gives the reader relevant information that he otherwise might not have. So yes, I prefer the current state of the article, independently of how it arrived there. —Frungi (talk) 01:40, 1 June 2013 (UTC)

Regarding the comment "it is a technical problem and should be dealt with at WP:VPT" - I'd like to point out that so long as two conditions exist - that talk-page posts are indented using colons and the MediaWiki software converts such markup to the <dl>...</dl> element - there is nothing that WP:VPT can do about this. We can try to change people's habits so that they use something other than the colon, which is I think a non-starter; or we can ask for the HTML generated by the colon markup to be changed to something other than <dl>...</dl>, which means bugzilla:, not VPT. --Redrose64 (talk) 14:27, 30 May 2013 (UTC)

Bugzilla then but I though VPT was the proper place first. As to people's habits that's what they're told to do in all the pages linked to WP:INDENT and they don't mention lists in that context at any of them. I would go to VPT first because they might think of a different solution. Dmcq (talk) 15:31, 30 May 2013 (UTC)

i don't believe they mention the use of blank, un-coloned lines in the middle of a discussion, either; certainly no encouragement of it. (Or if there is, this should be addressed posthaste.) —Frungi (talk) 15:44, 30 May 2013 (UTC)

Indeed, the examples given do not use blank lines. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:16, 31 May 2013 (UTC)

In fact, I already did think of a different solution. The NVDA screen reader is the only screen reader that is reported to have a problem. The NVDA screen reader is an open source project. The Wikimedia foundation has paid developers on staff. The NVDA screen reader project would be happy to accept a code submission written by Wikimedia to make NVDA work better on Wikimedia pages. This would, of course, start with a low-cost feasibility study (I estimate less than a man-day for that) at which point a decision would have to be made as to whether to proceed. It would be incredibly stupid to ask the English Wikipedia's 48,240,540 registered users to follow a new guideline without first determining that my alternative solution is impractical. --Guy Macon (talk) 06:27, 31 May 2013 (UTC)

As has been pointed out to you more than once, no-one is asking users, including the many inactive registered users, to follow a new guideline. HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:16, 31 May 2013 (UTC)

Bullshit. You personally reverted a user for not following the portion of a guideline[24] that you yourself added two weeks earlier, and in your revert you quoted the wording you added. If that's not tellng someone what to do, I am the pope. Please stop claiming that "no-one is asking users to follow a new guideline". That is a total load of crap, and I am tired of hearing you repeat it over and over again hoping that nobody will notice what a steaming pile of manure it is. Please, cut the crap. --Guy Macon (talk) 06:11, 1 June 2013 (UTC)

That was under a different wording of the guideline. While that wording did apply the guideline to Talk pages, it has since been changed to the wording we’re currently discussing, of which Andy’s comment is true—it continues to be ambiguous in its scope. Directly below, I asked you a question directly related to the proposal in your previous post. Please stay on topic and answer it. —Frungi (talk) 06:38, 1 June 2013 (UTC)

If I understand what you’re suggesting, wouldn’t that break expected behavior with <dl>...</dl> everywhere else? Or do you mean that it should have behavior specific to Wikipedia? Either way, my feeling is that it would be better to fix or avoid bad page coding than to have other projects work around it. And LISTGAP is not a new guideline; I don’t believe it applies exclusively to mainspace articles, nor that it does not apply to ;: lists, but if you disagree, we should start a new discussion on that point, free of BRRD baggage. —Frungi (talk) 20:29, 31 May 2013 (UTC)

I believe we were talking about :, not ;:. If you are happy for the new sentence to be removed from the guideline in accordance with WP:BRD then we can remove it for the moment and set up another discussion about sticking it in. Dmcq (talk) 22:54, 31 May 2013 (UTC)

If you use : you get a <dl>...</dl> structure enclosing a <dd>...</dd> element. If you use ;: you get a <dl>...</dl> structure enclosing a <dt>...</dt><dd>...</dd> element pair. It comes to the same thing: it's a definition list. --Redrose64 (talk) 23:42, 31 May 2013 (UTC)

Exactly. : (and ;) is part of the ;: structure, even if you only use one of the two. (Though using ; without a matching :—a <dl>...</dl> containing only a <dt>...</dt>—results in invalid HTML.) —Frungi (talk) 23:56, 31 May 2013 (UTC)

I was referring to an actual guideline change that explicitly limits the scope of WP:LISTGAP, or explicitly includes Talk pages within it. The current text does not do either, though a reader may (correctly) infer that it is relevant to colon indentation. —Frungi (talk) 00:04, 1 June 2013 (UTC)

Oppose Well if people here won't try and fix the problem properly first and instead have this urge to go around causing unnecessary trouble to new editors, then the addition of the sentence "Note that any wiki definition lists, including talk page discussions, are formatted using HTML definition list markup." definitely gets my thumbs down. Dmcq (talk) 14:11, 30 May 2013 (UTC)
How would one "try and fix the problem properly"? What sort of fix would you suggest? I've already pointed out the longstanding T6521 elsewhere, and User:Quiddity here. It's a problem of use at this point, not a simple technical fix. —Frungi (talk) 14:14, 30 May 2013 (UTC)

Well thanks for something constructive. I just had a look at that bug and I see it has been added to bug 19719. It is rather disheartening that they are so slow fixing problems. Getting a move on with that bug would require more people to vote the bug on bugzilla so I wonder what its priority is compared to other things. Perhaps saying it is for accessibility might give more weight even though it has few votes. It does make me wonder even more though about exactly how much of a problem this really is but even so I'm always keen on the semantics being fixed so the text can be analysed easier. — Dmcq — continues after insertion below

I'll venture to guess that screen-reader users are a minority, and since this mainly affects them, it gets a minority of votes. IMO, they still deserve to be accommodated, even if that means we can't have blank lines in our comments. —Frungi (talk) 15:26, 30 May 2013 (UTC)

The main thing they talk about there is trying to distinguish between : used for a list with ; and used for indenting. It doesn't look like that would be too difficult in the vast majority of cases but I guess there will always be a few odd cases that occur but they shouldn't I think be too much of a problem. There also is the problem that the article and section tags in html5 seem to be about the closest to reply or response tags as they can be nested and each reply treated as an article in a section of replies. However using new html5 tags in wikipedia any time soon sounds problematic to me.

There also has long been talk about implementing a different format for discussions which is used elsewhere but that's never been adopted in the English Wikipedia. That might be another thing to go for. Dmcq (talk) 15:16, 30 May 2013 (UTC)

Here's hoping Flow gets implemented on Talk pages system-wide, and soon. —Frungi (talk) 15:26, 30 May 2013 (UTC)

Break for length – Policy change or Clarification?

So what do I have to do to replicate the problem with NVDA? Just using the default installation I either don't hear it or didn't spot it when it happened. Dmcq (talk) 22:58, 31 May 2013 (UTC)

I haven't installed it yet (pesky real world!). Did it just read you the text, as the only source I could find said it would? Did it say something like "definition list" or "definition"? Any indication of indent level?

Here is a test page that might be interesting: http://endoframe.com/css/html20 --Guy Macon (talk) 23:19, 31 May 2013 (UTC)

It says "list of <x> items" at the start of the HTML list and "out of list" at the end of the list; it doesn't tell the user there's a definition list, however. I've checked with the default settings and it still announces the lists. The speech viewer in the NVDA menu (activated by insert-n) may be helpful for people checking it out. I've created User:Graham87/sandbox19 as a demonstration of the problem; the first discussion does not contain line breaks between each list item, while the second one does. Graham87 07:01, 1 June 2013 (UTC)

Well that all indicates that a bit more attention should have been paid to semantics in the html. What basically this is all about is kludging a kludge. I cannot support causing trouble for the difference in usability this would give to blind people compared to the trouble elsewhere. I can support fixing the semantics in wikipedia by recognizing that : is used for indenting and it should be treated that way when doing that job.

If a klude fix is desired I would suggest asking someone to write a plugin for NVDA especially for Wikipedia or other sites that use the dl tag for indentation. I would suggest that if it detects a definition list is given without any definitions it be treated as indentation. That way the fix would eb more general than just Wikipedia. Dmcq (talk) 14:52, 1 June 2013 (UTC)

This seems like a good suggestion, acknowledging (but not accepting) that WIkipedia misuses the <dl> element while not demanding that the rest of the world work around our mistakes. I don’t think this means we should ignore WP:LISTGAP, but I approve (though I’ve never needed to use a screen reader, so take my opinion as you will). —Frungi (talk) 20:14, 1 June 2013 (UTC)

I find it curious that you don’t think we should ignore WP:LISTGAP, but at the same time you yourself completely ignore WP:L, which clearly defines what is and what is not a list on Wikipedia. --Guy Macon (talk) 07:28, 2 June 2013 (UTC)

It's at WP:L#Description (definition, association) lists. Perhaps that also needs a clarification that any text that uses the colon Wikimarkup creates such a list. --Redrose64 (talk) 08:47, 2 June 2013 (UTC)

That's getting back to confusing the semantics as far as users are concerned and the implementation using the wiki software which contributed to the problem. I simply do not see the need to push that at new editors or to tell them in any shape or form that they're setting up definition lists when they're replying to a comment or indenting some text. Never mind talking about editing heir comments because of that. That can be documented as the current technical implementation somewhere but it is not what it is in user terms. For Wikipedia I see that as a problem requiring a technical fix and not one of such a magnitude that it needs to become part of the daily life of editors.

By the way I'd be interested in how common actual definition lists using ; are in Wikipedia if anyone can find that out. If the wiki software to distinguish the uses would be difficult it might be easier to use a different symbol for actual definition lists. Dmcq (talk) 09:30, 2 June 2013 (UTC)

Also as far as the text this dispute is about. I think it would be better if somebody wants something like that in to start another section about indents in talk pages instead, and give the recommendation that space lines be avoided or marked by having an equal number of colons as one of the paragraphs beside it. There could be a bit of explanation too about how the effect is implemented for those who want some technical insight. Dmcq (talk) 10:35, 2 June 2013 (UTC)

Statements such as Redrose64's "Perhaps that also needs a clarification" above are really starting to piss me off. If not for WP:POINT, I would love to go there first, make a "clarification" that it doesn't apply to talk page comments, and give certain individuals a taste of their own "Bold, Revert, Revert, and discuss forever" medicine. I predict that suddenly the rules would change and the same editors who say that their "clarification" doesn't need consensus would say that my "clarification" does need consensus.

It's nice to imagine, but of course I can't actually do any of that, because of WP:POINT, no matter how badly that point needs to be pounded in. What I can do, however, is to once again bring the page back to the state it would have been in without the blatant disregard of WP:BRD and WP:TALKDONTREVERT clearly those who think that BRD does not apply to them are in no hurry to seek consensus -- why bother when you can simply insert any guideline change you like and keep it there with WP:BRRD? I am going to wait a bit just in case someone has an actual reason why they think BRD doesn't apply to them, but an edits that "clarifies" a guideline against consensus has to go, as evidenced by Redrose64's apparent belief that he can do it again with another guideline. --Guy Macon (talk) 11:11, 2 June 2013 (UTC)

Guy, I’ve hinted at this before, but I fear you may be focusing so much on the issues surrounding the process of editing this guideline that you’re not actually considering how the guideline can best benefit Wikipedia and its users.

As to your WP:L argument, that page does not and can not define what lists are, but lays out best practices for using them. —Frungi (talk) 18:44, 2 June 2013 (UTC)

Dmcq, I started a section about that text (actually addressing the broader issue that the text pertains to) below,, but only Graham has responded so far. Given how divisive the question appears to be from this discussion, I expected more activity there. As for the worry of too much technical detail, I would argue that some detail is relevant when discussing the relationship between wiki markup, HTML markup, and accessibility, as this page does. —Frungi (talk) 17:58, 2 June 2013 (UTC)

I do not consider the change related to this discussion as a clarification because indents are not semantically the same as lists. That 'technical detail' is very much to the point. Dmcq (talk) 21:57, 2 June 2013 (UTC)

According to the HTML (which is how Wikipedia is primarily rendered when not in print form), semantically speaking, we use lists to indent. What we mean by it is disparate from the semantic meaning of it, which is defined by the W3C, not us. —Frungi (talk) 23:53, 2 June 2013 (UTC)

The above claim is factually incorrect. When Wikipedia is not rendered in print form, the standard is Digital Visual Interface or Video Graphics Array, not HyperText Markup Language. and we use pixel positioning to indent, not definition lists. I can prove it: I looked at the signal coming to my screen with an oscilloscope and did not see any hint of HTML. This shows the basic flaw in your argument; once you made the decision (arbitrarily, unilaterally, and without consensus) that WP:L doesn't mean what it says it means and what 99.9% of those who read it think it means, but instead decided (once again arbitrarily, unilaterally, and without consensus) that it "really means" a later step in the string of protocols and formats between a server in Florida and my screen in California, that means that I have just as much right to arbitrarily decide that WP:L "really means" what my browser/operating system sends to my display, not a subset of what the server in Florida sends to my PC in California. I say "subset" because what the server in Florida sends to my PC in California starts with the text string "HTTP/1.1 200 OK", not "<!DOCTYPE html>" as you appear to believe. Please note that my "clarification" that what WP:L really means is DVI or VGA is just as valid and just as technically correct as your "clarification" that what WP:L really means is HTML. Both are valid transformations from the Wikimarkup that WP:L actually talks about. --Guy Macon (talk) 02:10, 3 June 2013 (UTC)

I’m sorry, but your reasoning is so faulty that I’m honestly having difficulty finding your point. Wiki markup directly translates to HTML. That means that any given wiki markup is interpreted in exactly one way, which replaces the marked-up text with a set HTML element or elements. This is because Wikipedia is primarily a Web site whose content is displayed by Web browsers. The specifics of the translation can be changed by the Wikimedia Foundation, but I believe it’s been relatively stable over the years, and it’s foolish to try to divorce wiki markup from HTML—even more so when discussing issues of accessibility. I have no idea why you insist on appealing to absurdity, but please stop. If you believe that wiki markup has any meaning outside of simplifying the markup so that we don’t have to directly edit HTML, I would be interested to hear that argument. —Frungi (talk) 03:23, 3 June 2013 (UTC)

I think I’ve worked out what you’re trying to say: that someone (who?) claimed (where?) that WP:L pertains to HTML when it really doesn’t. Having re-read both my and Redrose64’s comments after you brought up WP:L, I can’t find that claim anywhere in them. If you were reacting to this edit by Pigsonthewing, you weren’t responding to him here (he hasn’t participated in this discussion for some time), and that guideline’s Talk page (or his own Talk page) would be the place for it. —Frungi (talk) 03:54, 3 June 2013 (UTC)

I was under the impression this discussion was about the addition of " Note that any wiki definition lists, including talk page discussions, are formatted using HTML definition list markup." to this guideline in the section about lists implying that any guideline here about lists applies to indentation on talk pages. And especially Rerose64's assertion that it was just a 'clarification' and so saying this guideline did not apply to indentation was in fact the change affected by BRD. And then they come along with another 'clarification' just above for another guideline. I have just gone and rephrased their change to WP:L to not mix up semantics and implementation. Dmcq (talk) 06:18, 3 June 2013 (UTC)

Redrose64 did not make that addition to WP:L. Pigsonthewing did. Guy went way off-topic here, at least if I’m interpreting his reply correctly. —Frungi (talk) 07:12, 3 June 2013 (UTC)

As to it being foolish to divorce markup from HTML are you saying that no attempt should be made in future to implement replies on talk pages using the article and section tags of HTML5? Or are you saying that people really really meant to define items as replies and therefore even if we used article section for threaded discussions in future a different markup should be used so older discussions can be read a definition lists? Dmcq (talk) 06:45, 3 June 2013 (UTC)

No; I’m saying we can’t refuse to discuss HTML when discussing the effects of wiki markup. Guy seems to disagree vehemently, and I can’t understand why without assuming things about him which I would rather not. —Frungi (talk) 07:12, 3 June 2013 (UTC)

I thought this was entirely over this edit and the 10 edits that follow. 50,000+ characters of discussion here, and 20,000+ at WT:PG, so far...

I recommend not replying, and thereby not feeding the molehill. There are real articles/issues that need attention... –Quiddity (talk) 07:19, 3 June 2013 (UTC)

The linked edit reverted an edit that the addition to this guideline allegedly condones, when in fact WP:TPO is the applicable guideline. But this discussion is really a disorganized mess about multiple questions at once, and we’d probably be best off closing it, since we already have an RfC about the central issue below. I don’t think it would be kosher for me to close it, so I’ll ask at WP:ANI. —Frungi (talk) 07:50, 3 June 2013 (UTC)

Well I don't think much of your "I can’t understand why without assuming things about him which I would rather not". You seem unable to see simple distinctions, is that WP:IDONTHEARTHAT or shall we lay off attacks like that and this and stick to the actual issuse? Dmcq (talk) 08:03, 3 June 2013 (UTC)

I was being sincere, and I meant no offense. I genuinely don’t understand it, assuming that he is a reasonable person. (It’s always easier to explain opinions you don’t like by assuming the people who hold them are irrational; I don’t do that.) As for distinctions, if you mean between wiki markup and HTML, there really aren’t any; wiki markup is essentially a simplified method of entering HTML. —Frungi (talk) 08:53, 3 June 2013 (UTC)

Wrong. Wikimarkup is essentially a simplified method of telling a digital monitor when to turn pixels on and off. I don't see what is so hard to understand; I say that my proposed "clarification" of WP:L is just as valid and just as technically correct as your "clarification" of WP:L. I say that it really means DVI. You say it that it really means HTML). Both "clarifications" are arbitrary, unilateral, and without consensus, but that's what happens when your starting premise is that WP:L does not mean what it says it means. --Guy Macon (talk) 09:45, 3 June 2013 (UTC)

I made no clarification to WP:L beyond that it “does not and can not define what lists are, but lays out best practices for using them.” Please stop replying to my comments with grievances about a user who hasn’t been participating in this discussion for days. —Frungi (talk) 09:50, 3 June 2013 (UTC)

To your still-faulty analogy: There is no one-to-one relationship between wiki markup and the final output. It’s all very dependent on the user agent that displays the page; put simply, a thousand different devices could display any given Web page (such as a Wikipedia article) in a thousand different ways. However, there is a one-to-one relationship between any given wiki markup and the HTML that it generates; and wiki markup and any “raw” HTML are the only things we as editors have control over. I hope this clears things up. —Frungi (talk) 11:16, 3 June 2013 (UTC)

I think I can fairly say the sentence under dispute does not have consensus for inclusion in the way it has been whatever about it being a 'clarification' as it has been used to change comments on talk pages against WP:TPO. I'll remove the offending sentence and put in another section instead explicitly talking about indentation and pointing out the talk page guidelines. Dmcq (talk) 08:03, 3 June 2013 (UTC)

I disagree: WP:TPO allows edits to correct formatting and layout. The editor was Wrong to persist in re-reverting the Talk edits, but I don’t currently think the original edit was wrong per WP:TPO. But yes, such edits should be discouraged at the moment, and the below RfC should settle whether or not the permitted fixes include this guideline. If it does, then we can discuss LISTGAP/TPO. Until then, there’s really no point discussing them here. —Frungi (talk) 08:53, 3 June 2013 (UTC)

This discussion is 'Policy change or Clarification?'. I am removing the 'clarification' because it wasn't one. I am upholding WP:BRD. That is a differnet matter from your other discussion. Dmcq (talk) 09:09, 3 June 2013 (UTC)

Again, it’s dependent on the scope of the guideline. If it applies to Talk pages, then the clarification is valid, or can at least be considered. If it does not, the added text violates that scope. It’s pointless to debate until the scope is clear. —Frungi (talk) 09:19, 3 June 2013 (UTC)

It isn't a clarification. Otherwise you wouldn't need an RfC. It looks like Pigsonthewing is insisting on sticking in the disputed bit despite my putting in a separate section about it so it looks like the disputed tag will have to stay and this discussion will continue, especially as he points to the section I put in as supporting the action in that section whereas it doesn't. I think this discussion should be counted as a behavioural dispute about Pigsonthewing. I notice from their talk page they were topic banned from something else. Dmcq (talk) 09:37, 3 June 2013 (UTC)

Well if Frungi's edit to remove that sentence and put the disputed tag under indentation pointing at the RfC here isn't changed back I think we can consider this discussion closed. Dmcq (talk) 10:11, 3 June 2013 (UTC)

(edit conflict) I’ve reverted the revert pending the RfC decision, and moved the {{Under discussion}} template to your section. User:Pigsonthewing and everyone else, please don’t add any clarification pertaining to any namespace but Main until the matter is settled. —Frungi (talk) 10:14, 3 June 2013 (UTC)

Discussion of recent controversial changes to this guideline

At 09:53, 3 June 2013, User:Frungi Reverted[25] a Bold change[26] to this guideline made by User:Pigsonthewing at 09:24, 3 June 2013. I believe that the revert was correct, and I would like to Discuss why per WP:BRD and WP:TALKDONTREVERT. Certainly this sort of behavior[27][28][29][30][31][32] is not appropriate, especially from an editor with a long history of previous blocks.[33]

When an editor holds a particular interpretation of a Wikipedia guideline and adds a "clarification" to make his interpretation an explicit part of the guideline, another editor may disagree with the interpretation and object to the addition, and that editor may revert the change. In such cases, Wikipedia policy says that the editors should discuss the edit on the article talk page. In particular, the first editor may not revert again and discuss with the edit in place.

I object to the addition. Here are my reasons:

First, it adds a clarification that no reasonable person would have arrived at simply by reading the guideline. It is a long-established principle that when a portion of a page has stayed the same for a long time, that means that the editors who have read the page and possibly edited other portions of the page have given a weak form of consent to the wording. This is especially true of often-cited guidelines. Alas, this only works for the actual words of the guideline, not for an interpretation that virtually nobody can see without an added "clarification." Because of this, we need to seek consensus on such changes.

Second, it results in every editor now being subjected to a guideline that nobody knew existed before the "clarification". Major changes require extensive discussion before making the change..

Third, there is no compelling proof that the problem it tries to solve actually exists. There are arguments both ways which require discussion and evaluation before making the change.

Fourth, in my opinion as an engineer and as a software developer, even if it is assumed that this is a real problem, the proposed solution appears to be a particularly brain-dead solution that was devised by someone using hammer logic ("if the only tool you own is a hammer, all problems look like nails"). Changing the long-established behavior of 48,240,540 registered users plus an unknown number of IP editors is a solution that should only be considered after it has been determined that no software change can solve the problem. In this case there has been no detailed discussions about changing how Wikimedia generates HTML, and no detailed discussion about changing how screenreaders respond to HTML. These approaches need to be researched and discussed before considering this change. I would also point out that if we change this guideline, that only helps users of the English Wikipedia, whereas changing the Wikimedia software helps all users of all wikis that use Wikimedia, and changing the screen reader software helps all users of that software on all websites.

For all of these reasons, it was correct to revert this edit and it will be correct to revert all similar edits. We need to seek consensus of the wider community about the best way to approach these sort of accessibility issues. --Guy Macon (talk) 11:22, 3 June 2013 (UTC)

We've got the RfC ~~above~~ below about the actual contentious part of the guideline. I think the BRD etc business is a different thing, it was getting towards being something the admins should do something about but hopefully it has all got back on track to normal discussion again I think. You might like to discuss at the talk page of BRD or continue at the one at POLICY about it I guess but it isn't an accessibility page problem unless it is currently happening here I think. Dmcq (talk) 11:33, 3 June 2013 (UTC)

To your first point: This is untrue if the editor is aware of what the colon markup actually does. To your second: I would argue that that applies to WP:ACCESS as a whole rather than the section in question. And that is truly a shame.

If the only tool you have is a hammer (as I’ve said elsewhere on this page, wiki markup and raw HTML are the only things we as editors have any direct control over), what else are you supposed to do? This has been a problem (T6521) for as long as the practice was in… practice, and is highly unlikely to change until all Talk pages are replaced by another paradigm like m:Flow (which I greatly look forward to). In the meantime, it does no harm to do what we can to mitigate the problem, and it’s unreasonable to expect other projects to work around our problems instead.

As for the revert: The only reason that is necessary, and the reason it was done, is that the reverted edit appeared to be WP:edit warring. —Frungi (talk) 11:38, 3 June 2013 (UTC)

This matter s discussed at length, above. Your latest post includes a number of straw men, which are already addressed there. the RfC below is not about "the actual contentious part of the guideline", but about whether the guidelines as a whole applies to talk pages. The change contested here is not about that; but about whether or not we point out to editors that the indisputable fact that talk page indentation with colons is rendered using HTML association lists. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:02, 3 June 2013 (UTC)

A change which assumes and implies that the guideline does apply to Talk pages when it's not at all clear that it does (if it doesn't, then why mention the fact here?). Which is why I ask that any further discussion of the matter wait until that question is settled. —Frungi (talk) 12:14, 3 June 2013 (UTC)

What's the problem here? I see Andy Mabbett's original change, "As noted above, this includes talk page discussions, which are formatted using HTML definition list markup." as technically correct, and based on a technical issue of MediaWiki implementation and HTML generation that's independent of policy. I appreciate the point raised above that making changes to legacy guidelines is a problem because it's effectively retro-active policy changes invisibly affecting many editors, but in this case the "new" addition really is just a clarification that makes explicit an issue that has always been there at an invisible technical level: MW's use of list markup and its susceptibility to accidental list breaking by seemingly unimportant whitespace in wikitext. Few editors are aware of this problem.

I don't know what our policy or guidelines state and whether we're in favour of accessibility for the generated HTML or accessibility for wikitext authors (the whitespace makes editing easier). It's a MW bug that these two worthwhile goals are set against each other by a parser limitation.

I just don't see Andy Mabbett's change as a problem. He's not inventing a new problem here, nor even changing a guideline, merely making the guideline readers (both of you! Who reads these things anyway?) that there is an issue, so that editors can at least be aware of it and apply their own judgement. A competent "editor on the Clapham omnibus" might be expected to supported accessibility and to use their judgement reasonably when choosing their own formatting style, but the technical glitch that whitespace in our regular talk: formatting causes a HTML problem can't be expected to be widely known. This is a simple objective observation of technical fact. No editor, not even Andy Mabbett, should be pilloried for highlighting such issues. Andy Dingley (talk) 12:18, 3 June 2013 (UTC)

Agreed on all points, except that the editor then used his addition to justify edit-warring over a Talk page (see the edit history for Template talk:Track listing). This set my fellow editors against the clarification, and not on its own merits, rather than against the editor who misused it. —Frungi (talk) 12:27, 3 June 2013 (UTC)

Andy, the problem is here: [34] he edited another editor's work while quoting a guideline that he himself added two weeks previously, and he has been trying to insert variations of it ever since. And "As noted above, this includes talk page discussions, which are formatted using HTML definition list markup" is most assuredly not technically correct. only the last bit is technically correct. It is not true that the policy includes talk page discussions, and it is not "noted above". This is a major change of a guideline, and requires consensus. Frungi is right. Talking about one editor who doesn't think BRD applies to him is a distraction. We should instead focus on the issue at hand. Not on whether the guideline already forbids extra lines in talk page threads -- it doesn't -- but whether it should be changed so that it does. That's a legitimate question. --Guy Macon (talk) 13:36, 3 June 2013 (UTC)

Not exactly. On the matter of forbidding blank lines on Talk, it’s simple: if the guideline (meaning the whole of WP:ACCESS, not one small part of it) applies to Talk pages, then so does the bit about the markup they use (unless a later discussion determines that it shouldn’t). If not, then not. The base issue is where the guideline as a whole applies or not. —Frungi (talk) 13:49, 3 June 2013 (UTC)

Oh, well in that case, burn the heretic. Refactoring talk: is always a problem and needs a damn good reason to justify doing it. This is not such a reason. Andy Dingley (talk) 13:53, 3 June 2013 (UTC)

I didn't refactor anybody's comments; I removed white space from between them. The whole of this section is a response to that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:09, 3 June 2013 (UTC)

Forgive me, but I believe it’s actually in response to your violations of WP:TPO (“stop if there is any objection”) ~~and WP:3RR~~. —Frungi (talk) 14:12, 3 June 2013 (UTC)

[ec] 3RR? Where? Why wuold I forgive you for false accusations? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 3 June 2013 (UTC)

[35] [36] annnd… My apologies; I misread the edit history. Still, 2RR is pretty grievous for someone else’s comments, methinks. —Frungi (talk) 14:36, 3 June 2013 (UTC)

And, again, those are not edits to anyone else's comments. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:46, 3 June 2013 (UTC)

Not content-wise, no, but edits to another user’s (Lucia Black) comments they are. —Frungi (talk) 14:53, 3 June 2013 (UTC)

This is classically typical of your behaviour in many past cases: take an action that's not clearly prohibited, repeat it even if it's resisted, and keep doing so until the little people learn their proper place. It's not the action of itself that's the problem, it's your dogged refusal to accept that Andy Mabbett, sole arbiter of WP, might be out on a limb. Andy Dingley (talk) 14:21, 3 June 2013 (UTC)

(Moved by Frungi (talk) from the RfC below to a more appropriate section; comment directed at User:Pigsonthewing)
The bit I can extract from that is you think anything and everything one can do for a disabled person is necessary and must be done. I disagree with that. The primary function of Wikipedia is to produce an encyclopaedia. WP:TPO says "It tends to irritate the users whose comments you are correcting". If accessibility concerns can be brought up on talk pages in a civil way fine. However I cannot support having weird technical arguments and edit warring with something you'd just stuck into this guideline like you did at Template talk:Track listing. How about a little balance and treating people who aren't disabled with some respect too? I would prefer the quoting of wikilinks as a full and sufficient reason to be reserved for article. Dmcq (talk) 12:26, 3 June 2013 (UTC)

There have been no "weird technical arguments". However you choose to misrepresent what I wrote doesn't mean that the words you attempt to put into my mouth are mine. Your comment about WP:TPO remains an irrelevant straw man. WCAG guidelines are an international, ISO standard for making web pages accessible. Please cite the part of that standard that says "except encylopedias" or "except discussions". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 3 June 2013 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 3 June 2013 (UTC)

We haven't "enacted" the WCAG guidelines. — Preceding unsigned comment added by Arthur Rubin (talk • contribs) 13:39, 3 June 2013 (UTC)

From this guideline’s lede: “We aim to adhere to WCAG guidelines 2.0 (aka ISO/IEC 40500:2012) on which the following suggestions are based.” —Frungi (talk) 14:18, 3 June 2013 (UTC)

Following sentence is 'Articles adhering to them are easier to read and edit for everyone.' As WP:POLICY says "The policies, guidelines, and process pages themselves are not part of the encyclopedia proper. Consequently, they do not generally need to conform with the content standards". Dmcq (talk) 14:15, 3 June 2013 (UTC)

Nevertheless, we have an obligation to consider other readers whenever we contribute to Wikipedia, especially those readers who may have disabilities. It is ludicrous to suggest that we only need adhere to WCAG guidelines for articles, because any of the namespaces may be read using assistive technology. I see that no case whatsoever has been made for excluding large parts of Wikipedia from guidance on accessibility. --RexxS (talk) 15:57, 3 June 2013 (UTC)

First off, let's dump the pointless idea that following WCAG is a good idea. Those standards are badly broken and any credible authority on accessibility will explain why (if you're looking, try starting with Joe Clark and the "WCAG Samurai"). Andy Dingley (talk) 16:12, 3 June 2013 (UTC)

While it's good to see you move from baseless ad hominem to something seemingly more substantive, WCAG Samurai was a 2007 critique of WCAG1.0, which was used to inform the development of the current WCAG2.0. As http://www.wcagsamurai.org/ (last updated Feb 2008, before WCAG2.0 was published) says: "What WCAG Samurai was not doing... Writing errata for WCAG 2". But thank you, anyway. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:52, 3 June 2013 (UTC)

Simply: No. WCAG Samurai existed because WCAG 2.0 was seen as a failure to move beyond WCAG 1.0. It was a response to 2.0 As to the chronology, then the W3C moves slowly and WCAG 2.0 was widely distributed (and indeed, its wholesale rejection strongly suggested) long before its official publication date.

As to "baseless ad hominems", then you already a list of topic bans of quite extraordinary length, acquired through just this type of behaviour. Andy Dingley (talk) 17:22, 3 June 2013 (UTC)

Oh.,well, back to baseless ad hominems. You are right in one respect, though. I should have said "WCAG Samurai was a 2007 critique of WCAG1.0 and the early draft of WCAG2.0, which was used to inform the development of the final, much altered, and current WCAG2.0. As http://www.wcagsamurai.org/ (last updated Feb 2008, before WCAG2.0 was published) says: "What WCAG Samurai was not doing... Writing errata for WCAG 2"." Your claim that "WCAG... is badly broken" is a pile of steaming odure, either way. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:48, 3 June 2013 (UTC)

When two editors who have never behaved in such a way that they needed to be blocked (6 years for Andy, 7 years for me) both tell you -- an editor who has been blocked 32 times -- that your current behavior is the same sort of thing that got you blocked so many times before, that is hardly a "baseless ad hominem". This reminds me of the drunk driver who was driving the wrong way on the freeway. Upon hearing on the radio (over the honking horns) that there was a drunk driver who was driving the wrong way on the freeway, he peered through his windshield, noticed all of the headlights heading toward him, and exclaimed "My God! There are DOZENS of them!!" --Guy Macon (talk) 15:52, 4 June 2013 (UTC)

In regards to the claim the Joe Clark's WCAG Samurai group only criticized version 1, please see

To Hell with WCAG 2 by Joe Clark. Also see

WCAG 2.0: The new W3C web accessibility guidelines evaluated By Trenton Moss,

Lachlan and Steve talk WCAG 2.0 by Lachlan Hunt and Steve Faulkner, and

WCAG 2.0: when I want a beer, don’t give me shandy by Bruce Lawson.

The WCAG standards are very useful when applied intelligently, but they are also flawed in some ways, and they make a very poor coatrack for Wikipedia editors who craves power over other editors and want to "fix" the formatting of what other editors write through reverts rather than through polite requests. --Guy Macon (talk) 16:38, 4 June 2013 (UTC)

I addressed the WACAG1.0/2.0 issue in the comment to which you respond. As for your your baseless ad homnem, shove it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:52, 4 June 2013 (UTC)

Guy: Here is the page for the WCAG 2.0 W3C recommendation. It’s dated December 2008. All of your links except for the YouTube video are from 2006; the video is from June 2008. This is a genuine question, since I have no idea: Was WCAG 2.0 locked between 2006 and 2008, or some other event that caused no changes to be made? —Frungi (talk) 18:01, 4 June 2013 (UTC)

It has been four or five years since I last examined the change history and compared it with the various criticisms, so correct me if I misremember something. The change history is at [ http://www.w3.org/WAI/GL/WCAG20/change-history.html ], and from there you can get to summaries and actual diffs. Basically, it looks like they did a couple of things. They went over everything and made somewhat shorter, a lot more readable. and made it more clear without really changing the meaning. They moved away from being overly specific in some areas, making it more future proof. And they introduced new (and usually quite good) material to cover things that the document didn't even mention before. When you drill down from the specific criticisms, you pretty much find that they apply equally well to the 2006 and 2012 versions. And maybe they should; noting that someone has a criticism doesn't imply that they are right, and some of these things are very much matters of opinion. As I said, I think the result is quite good, but you still need to use your brain, which of course governments and big corporations have a problem with. They want a bunch of rules that a monkey can follow. How many times have we seen alt text that is just "" with no actual text? That is just there so that a box can be checked or a validator program shows one less error. It does nothing for the visually impaired. --Guy Macon (talk) 19:15, 4 June 2013 (UTC)

That explains a lot, thanks. Only slightly better (though equally unhelpful, and I’m sure no more or less “compliant”): alt="picture" —Frungi (talk) 19:34, 4 June 2013 (UTC)

Bruce Lawson has just prefixed the page cited above with:

I’ve seen this page used as supporting evidence to say that the final WCAG 2 guidelines don’t matter. Please note that I was criticising a previous, draft version of it. This page is no longer current; it’s dated 2006 whereas the final guidelines are dated 2008.

I think that's fairly clear. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:33, 4 June 2013 (UTC)

Guess that answers that. Thanks! —Frungi (talk) 18:53, 4 June 2013 (UTC)

Collapse and strange multicolumn markup

Pi vs π

Navbox coloring

Horizontal lists in navboxes

CSS version 1 (obsolete)

CSS version 2

Moving forward

Navboxes

Color of wrestling templates

The color of meat

Bot to fix headings

About Image Mapping and Captions

Signature color for Vermont

Alt text for "gallery" is coming!

Update of the "Color" guidelines

The color of New Mexico

Heading issue in 'Documentation' template

Extra Space At The Bottom, Could Be A Bug

Screen reader interpretation

Help

Task force

RFC: restructuring of the Manual of Style

Use of tiny superscripts

Timeline Template is Inaccessible as Graphical Info

New template requested — Discreet abbreviation

History section headings

Documentation heading levels

Template: United States political party shading

Screen reader CSS

Article feedback tool

Accessibility of sigs

Road junction tables

NBA color

Question

HLIST

Screen reader user input needed

daggers

Layout tables

Accessibility of lists at "Five pillars" page

Ice hockey boxes

Superscript, subscript characters

style="font-size:... vertical-align:..." for super/subscripting

Snooker templates

Question about symbols

Image size discussion at Manual of Style talk

Template:Infobox single and <small> tag

Heads up about problem with template converted to use plainlist

something that might be of interest to the editors here

Signature colour argument

Hlist separators

Timelines

Headings: avoid pseudo-headings

Proposal to change alt text for thumbnails

Proposed change: Resolution

Proposed changes for the "article structure" sections

List of The Simpsons video games

Use of "rowspan" in tables

Accessibility of sigs

Track listing template

Neopaganism-sidebar

Small print

Link color in sidebar templates

Struck-though text

Template:DRC Muzito Cabinet I

Table columns, DIVs columns

Newcastle Knights

International Standard

Video and audio subtitles

Supreme court opinions

Template:Storm colour

Template:Lithuania topics

Hover Text

RfC: Section headings for horizontal navigation templates

Maps and colour blindness

Military ranks of Argentina

Fails?

Confusion

Logically, surely Other languages should follow Text?

Accessibility of new notifications system

WP:NOSTRIKE and WP:REDACT