Wikipedia talk:Manual of Style/Accessibility

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)

including talk page discussions

Note: I have marked the relevant section in the document as {{under discussion}}. Please remove the template when consensus is reached. davidwr/(talk)/(contribs)/(e-mail) 00:30, 28 May 2013 (UTC)

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

http://en.wikipedia.org/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 < br/>) 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<br /><br />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:

1. 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.)
2. 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?

Note: I have marked the relevant section in the document as {{under discussion}}. Please remove the template when consensus is reached. davidwr/(talk)/(contribs)/(e-mail) 18:54, 28 May 2013 (UTC)

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".[1]

Fact: I provided a citation[2] 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".[3]

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")[4] and subsequent talk page edit summary ("no "change of policy" involved in making editors aware"),[5], 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[6] of a Bold edit[7] 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)[8] and administrator Arthur Rubin ("It's a policy _change_, not a "clarification")[9] 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."[10] The language about screen readers that has been so badly morphed over the last two weeks was added in 2010.[11]

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: [12], [13]. --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.[14] (Following WP:BRD: BR.)

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

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

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

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

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:

1. It's not a policy page, it's a Manual of Style page.
2. This addition is not a "rule" to be followed, it's a description of the way the software works.
3. 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)
4. It can be seen to break, even more easily, by adding a blank line between (#) numbered list items.
5. It's been known as being problematic ever since it was conceived. It's been an official bug (bugzilla:4521) since 2006.
6. 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 <br /> 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,123,939 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[18] 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 Template:Bug 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[19] a Bold change[20] 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[21][22][23][24][25][26] is not appropriate, especially from an editor with a long history of previous blocks.[27]

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,123,939 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 (Template:Bug) 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: [28] 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)

[29] [30] 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)

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 <span style="text-decoration:line-through;">...</span> 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 < i>, 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 < u> to < i>.) — 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)

RfC: What is the scope of this guideline?

Much of this page pertains directly to articles, but could just as easily apply to project pages or Talk pages. What is its scope? Where should it apply, and where should it not? Is there a limit? Personally, I think the scope should be as wide as possible, and the site should be universally accessible to everyone. But some editors clearly disagree with my take, so I’d like to hear theirs, free of all of the above drama. —Frungi (talk) 06:45, 1 June 2013 (UTC)

I think this guideline should be applied everywhere, where practical. The strikethrough discussion above is one example of where it would be almost impossible to apply it on all pages. Graham87 07:14, 1 June 2013 (UTC)

It is sensible to try and follow guidelines like these everywhere but try harder with article pages. A guideline can always qualify where it is supposed to apply. This is just a general observation and does not mean I approve of people hassling new editors and officiously editing other people's comments. See the first sentence of WP:TPO. Dmcq (talk) 20:20, 2 June 2013 (UTC)

This particular discussion isn’t about whether or not we should edit other editors’ comments to make them comply, and I ask that we not discuss that in this section. I had considered creating a new section to specifically discuss that question, but decided to wait to see if this discussion would render that one pointless. —Frungi (talk) 20:55, 2 June 2013 (UTC)

Articles Only, But... I do think we should and must encourage accessibility across the entire encyclopedia, articles, talk pages, project pages, etc. However, I don't believe that a broad mandate across all those spaces fits within the Manual of Style, which is pretty exclusively dedicated to the article space. It may be worth considering promoting this section outside of the Manual of Style, but I really do have some concern about pushing the Manual of Style outside of article space. --j⚛e decker^talk 22:47, 2 June 2013 (UTC)

Very good point. Accessibility should probably be a policy or guideline in its own right, not just part of the MOS. How would we go about proposing that? —Frungi (talk) 23:48, 2 June 2013 (UTC)

It used to be a guideline in its own right, but was recategorised to be part of the Manual of Style in this edit in September 2006 with no discussion that I can find (the user who made that edit was on a guideline-sorting spree at the time). One advantage of it being part of the Manual of Style is that it is automatically part of the featured article criteria, among other things. Graham87 03:27, 3 June 2013 (UTC)

A lot of the rest of the manual of style is just good practice elsewhere as well. However I don't think it should in general apply to talk pages or even WP: pages with quite the same force as it does to articles. Wikignomes going around beautifying things is fine for articles and not a bad thing for WP: pages but in the context of talk pages that sort of thing done by people with no social understanding can be a real menace. The point of Wikipedia is to produce an encyclopaedia and people are secondary as far as article are concerned and that what the first 3 points of WP:5P says. However on talk pages civility and consensus are the important things and that is the fourth point, they are important too on the articles but the talk pages are where the discussion is done. If particular parts of this guideline are good for talk pages then the talk page guidelines should explicitly refer to the particular parts here that are relevant. Anything else is a 'would be nice' that can be conveyed as general practice but people are totally within their rights to reject. Dmcq (talk) 10:00, 3 June 2013 (UTC)

Referring to accessibility fixes as "beautifying" and "would be nice" belies a fundamental underestimation, if not a total misunderstanding, of the issues at stake; and the former is a further straw man. All accessibility guidelines are "good" [sic: read "necessary"] for talk pages. Rendering talk pages inaccessible to some of our fellow editors is a blatantly uncivil act. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 3 June 2013 (UTC)

(Dummy reply for example purposes—see below.) —Frungi (talk) 13:56, 3 June 2013 (UTC)

Article space only unless explicit. Some of the guidelines should apply to all pages. However, the one we are talking about (elsewhere on this talk page; technically not here) detracts from readability and editability by sighted, but possibly otherwise disabled, readers and editors. I would have to ask Graham whether the blank lines make it easier for a blind editor to, well, edit the talk page, but I agree that the "Wall of text" could be, and in fact, has been, a problem for me. (Note that I'm violating the guideline here, as I've started a new list.) — Arthur Rubin (talk) 13:39, 3 June 2013 (UTC)

You did not start a list; you started a paragraph outside of any list. On a brief tangent from the point of this RfC, addressing your concern about sighted accessibility, do you think it hurts readability for otherwise blank lines to contain colons? See my dummy reply above for an example. —Frungi (talk) 13:56, 3 June 2013 (UTC)

The dummy reply above works for me, in terms of helping readability in the edit window. What does the HTML look like? — Arthur Rubin (talk) 14:23, 3 June 2013 (UTC)

No change to the HTML, in fact. Also no change if done on the same indent level, in the middle of a comment or in between two users’ comments; lines consisting solely of colons are ignored. —Frungi (talk) 14:43, 3 June 2013 (UTC)

I should have checked better. So doing that is not a substitute. It just makes the source easier to read. I found I had to stick in something like &nbsp; to get a blank line in the output. A half line spacing sometimes would be good too as a full space line is normally too much but that's not going to happen except in a template. I find it annoying too sticking in blank lines at the top level but not sticking in blank lines in an indentation. I really can't see what the problem with implementing it in wiki software is - it isn't as though it can't detect very easily that it isn't in a definition list using semicolons in fact it has to carry around ernough of the state to do this properly just to detect that it should start or end a list. Dmcq (talk) 15:00, 3 June 2013 (UTC)

Agreed; <div>s or something would make much more sense. I’m not sure how the nesting could be implemented for screen readers, though. Still a bit off topic here, but is there anything we can do about that beyond Bugzilla (or just waiting for a new system)? This bug (Template:Bug) is six and a half years old. —Frungi (talk) 15:12, 3 June 2013 (UTC)

Article space only However its use can be encouraged elsewhere and any accessibility solutions should be consistent with it. WP:TALK and Help:Using talk pages are the right places to put things about talk pages and if there is a common accessibility problem in talk pages then that is the place for a guideline about it even if just a short description of the problem with the usual solutions and a link to a section here about it. Dmcq (talk) 14:02, 3 June 2013 (UTC)

Everywhere: Whatever arguments are adduced in support of accessibility considerations for those reading articles apply with exactly the same reasoning to all other pages on Wikipedia. That is assuming that disabled readers are just as welcome on other pages - and I've seen no arguments contradicting that view yet. --RexxS (talk) 16:05, 3 June 2013 (UTC)

Everywhere but it won't be mandatory for talk pages rather than for articles. It would be a guideline for talk pages, maybe like a how-to. Ramaksoud2000 ^{(Talk to me)} 01:46, 4 June 2013 (UTC)

I have a concern. Recently, several editors who are involved in this RfC were involved in a failed attempt to expand the accessibility guidelines that were specifically written for Wikimarkup lists so that they apply to all talk pages, arguing that the talk page you are reading right now is really a list, the comment you just wrote is really a list item, and thus the guideline that was written to apply to Wikimarkup lists applies to your talk page comments. Now I do not want to re-hash the merits of that argument in another place, but I am concerned that votes that agree with statements like "the scope should be as wide as possible" and "this guideline should be applied everywhere" might not be interpreted as meaning "the guideline on lists should apply to lists on articles, lists on talk pages, lists on template pages, etc." but rather "the guideline on lists should apply to lists, talk page comments, and various other elements to be specified later." Now I could very well be completely wrong on this, and there might not be anything to be concerned about, but if enough people vote for "apply the guidelines everywhere" and if such a result is interpreted the way I think it will be, then we are going to end up having Yet Another Battle, this time over whether those who voted on this RfC knew what they were voting for. --Guy Macon (talk) 02:47, 4 June 2013 (UTC)

Your "attempt to expand the accessibility guidelines that were specifically written for Wikimarkup lists so that they apply to all talk pages..." claim is false; as has been pointed out to you more than once. And this comment is a list item...

.. as is this one...

...and this one, as a cursory inspection of the HTML markup will show. Oh, and we don't vote on Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 4 June 2013 (UTC)

There was no "attempt to expand" this guideline to Talk pages. It was assumed that it already covered them, because why wouldn't it? Some, such as yourself, clearly disagree, and that's the point of this RfC—to determine where it does and does not apply, or where the community believes it should or should not.

As for whether anything that is implemented as a list should be treated as a list, or whether Talk indentation should be implemented as a list, I suppose that should be brought up with the technical folks at MediaWiki. To your legitimate concerns, if consensus here is that the guideline in general should apply to Talk pages, we can have a later discussion regarding the specifics, and I will save any further Talk/LISTGAP arguments for if and when that happens. But that is not the point of this RfC. —Frungi (talk) 13:44, 4 June 2013 (UTC)

Request to all participants in this RfC: Let's not yet discuss the specifics of how any particular part of the guideline may or may not apply to any particular quirk of the software outside of article pages. It's simply a waste of time while it's unclear whether the guideline applies outside of article pages, and muddies up the discussion. —Frungi (talk) 13:51, 4 June 2013 (UTC)

And hopefully it's completely unnecessary to say this, but: A decision here to apply the guideline to Talk pages is not license to apply it in controversial ways without further discussion. —Frungi (talk) 13:55, 4 June 2013 (UTC)

tabIndex'ing of Wikipedia

Hi folks, and @Graham87: in particular. I was wondering if I could get some input on this bug ticket, regarding the usage of tabIndex, especially when it comes to the sidebar collapsibles. In my opinion, we might as well set them to 0 now that the rest of the section has been elevated to be under an H2. —TheDJ (talk • contribs) 09:48, 1 June 2013 (UTC)