Misplaced Pages

Revision as of 01:54, 23 May 2013

• WT:ACCESS
• WT:ACCESSIBILITY

Manual of Style

This page falls within the scope of the Misplaced Pages: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.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Misplaced Pages 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. For information on Misplaced Pages'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 Misplaced Pages policies of Misplaced Pages's policy and guideline documents is available, offering valuable insights and recommendations.

	Accessibility
This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.AccessibilityWikipedia:WikiProject AccessibilityTemplate:WikiProject AccessibilityAccessibility

Misplaced Pages Help Project‑class

This page is within the scope of the Misplaced Pages Help Project, a collaborative effort to improve Misplaced Pages'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.Misplaced Pages HelpWikipedia:Help ProjectTemplate:Misplaced Pages Help ProjectHelp Project This page does not require a rating on the project's quality scale.

Archives

Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17

This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

Confusion

Hello,

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

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

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

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

Logically, surely Other languages should follow Text?

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

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

Accessibility of new notifications system

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

including talk page discussions

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

http://en.wikipedia.org/search/?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 Misplaced Pages 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 Misplaced Pages 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. Misplaced Pages guidelines, unless otherwise specified, refer to the intent of the text, rather than the Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages: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 proble. Graham87 01:54, 23 May 2013 (UTC)

WP:NOSTRIKE and WP:REDACT

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

There is an apparent conflict, yes: but I think that they are discussing two subtly different concepts. To me, WP:NOSTRIKE is concerned with text marked up with <s>...</s> <strike>...</strike> or <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 Misplaced Pages discussions a bit confusing when I first started here, but I got used to it. Graham87 01:41, 23 May 2013 (UTC)

• WikiProject Accessibility articles
• Project-Class Help pages
• NA-importance Help pages
• Misplaced Pages Help Project pages