Jump to content

Wikipedia talk:Manual of Style/Accessibility: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Line 274: Line 274:
::It used to be a guideline in its own right, but was recategorised to be part of the Manual of Style in [//en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Accessibility&diff=78331732&oldid=77425277 this edit in September 2006] with no discussion that I can find (the user who made that edit was on a [//en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20060929075324&tagfilter=&contribs=user&target=Radiant%21&namespace= 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 [[WP:FACR|featured article criteria]], among other things. '''[[User:Graham87|Graham]]'''<font color="green">[[User talk:Graham87|87]]</font> 03:27, 3 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 [//en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Accessibility&diff=78331732&oldid=77425277 this edit in September 2006] with no discussion that I can find (the user who made that edit was on a [//en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20060929075324&tagfilter=&contribs=user&target=Radiant%21&namespace= 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 [[WP:FACR|featured article criteria]], among other things. '''[[User:Graham87|Graham]]'''<font color="green">[[User talk:Graham87|87]]</font> 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. [[User:Dmcq|Dmcq]] ([[User talk:Dmcq|talk]]) 10:00, 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. [[User:Dmcq|Dmcq]] ([[User talk: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. <span class="vcard"><span class="fn">[[User:Pigsonthewing|Andy Mabbett]]</span> (<span class="nickname">Pigsonthewing</span>); [[User talk:Pigsonthewing|Talk to Andy]]; [[Special:Contributions/Pigsonthewing|Andy's edits]]</span> 10:38, 3 June 2013 (UTC)


== tabIndex'ing of Wikipedia ==
== tabIndex'ing of Wikipedia ==

Revision as of 10:38, 3 June 2013

WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.
WikiProject iconAccessibility
WikiProject iconThis page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.
WikiProject iconWikipedia Help Project‑class
WikiProject iconThis page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
ProjectThis page does not require a rating on the project's quality scale.

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

including talk page discussions

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

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)[reply]
Stop forum shopping. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:12, 21 May 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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)[reply]
@RexxS - Because it goes against one editors personal preference. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 22 May 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Nobody is calling for the "enforcing of a rule". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:01, 25 May 2013 (UTC)[reply]
  • 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)[reply]

Policy change or Clarification?

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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I have requested a clarification: Wikipedia talk:Policies and guidelines#WP:PGBOLD. --Guy Macon (talk) 23:55, 28 May 2013 (UTC)[reply]
Yes, I was only referring to the accessibility guideline in my message above. Graham87 02:49, 29 May 2013 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Cite, as requested. (Note edit summary). Also see: Negationism. --Guy Macon (talk) 14:37, 29 May 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Feel free to raise a Bugzilla ticket. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:03, 30 May 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
'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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Indeed, the examples given do not use blank lines. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:16, 31 May 2013 (UTC)[reply]
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 47,973,542 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]
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)[reply]
Here's hoping Flow gets implemented on Talk pages system-wide, and soon. —Frungi (talk) 15:26, 30 May 2013 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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 deckertalk 22:47, 2 June 2013 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
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. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:38, 3 June 2013 (UTC)[reply]

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 (talkcontribs) 09:48, 1 June 2013 (UTC)[reply]