Wikipedia talk:Manual of Style/Accessibility

"WT:ACCESS" redirects here. For the related wikiproject talk page, see Wikipedia talk:WikiProject Accessibility.

Paragraph breaks in a comment

Note: This discussion moved from user talk page to get more input.

Hello Timeshifter,

It seems that we have gotten into a few disagreements lately. I hope you know that I bear no ill will towards you; I firmly believe you are doing what you believe to be in the best interests of Wikipedia. I hope that our editorial disagreements do not stop us from being friendly towards one another.

I wanted to drop you a note about making paragraph breaks in a comment. Per MOS:PARABR, using multiple colons to create paragraph breaks is not accessible. We use list markup for comments, and generally one entry in the list should correspond to one comment. When you use colons like this:

:Here is one paragraph.
:Here is another paragraph.
:Here is a final paragraph. [SIGNATURE GOES HERE]

screen readers cannot distinguish it from:

:Here is one paragraph. [UNSIGNED COMMENT]
:Here is another paragraph. [UNSIGNED COMMENT 2]
:Here is a final paragraph. [SIGNATURE GOES HERE]

Instead, it is best to use {{pb}}, like this:

:Here is a paragraph. {{pb}} Here is another paragraph. {{pb}} Here is a final paragraph. [SIGNATURE GOES HERE]

{{pb}} works like <br>, but has different semantics. <br> is used to create a visual line break; {{pb}} separates two different paragraphs. Best, HouseBlaster^talk 03:41, 13 December 2023 (UTC)

HouseBlaster. I don't think this is true for talk pages.

It has been my understanding that the main thing is to avoid blank lines in indented comments.

--Timeshifter (talk) 03:56, 13 December 2023 (UTC)

It's not such a big deal for talk pages and lists without bullets, know. Screen readers read each list item (or pseudo-item in this case) on its own line, so the separation is still there. The only difference between the two forms of markup above is that in the one with explicit paragraph breaks, each new paragraph is actually read as a blank line. Graham87 (talk) 16:23, 13 December 2023 (UTC)

Graham87. So colons are fine? I have never seen {{pb}} used on a talk page. --Timeshifter (talk) 16:38, 13 December 2023 (UTC)

@Timeshifter: Yep, they're not worth worrying about. Graham87 (talk) 16:46, 13 December 2023 (UTC)

Thanks. HouseBlaster, Graham87 is a blind admin who uses a screen reader. --Timeshifter (talk) 07:06, 14 December 2023 (UTC)

This is a case of technically correct, but practically not. The MoS is mostly focusing on content, where yes, it is 'ideal' to do it like that,. But it's also ideal NOT to use : for indentation, and on talk pages, we do that anyway, because that's how it's been done since 2001 and it's hard to break a habit. It's also very low impact, as Graham also stated in the actual screenreader experience. The one thing that is really annoying is to have double line breaks, because that creates a new list, which is very disruptive in the screenreader annotations. —TheDJ (talk • contribs) 09:49, 14 December 2023 (UTC)

TheDJ and Graham87. Just so I and others are clear, you are talking about a blank line when you talk about double line breaks. For example, if I added a blank line between this comment and the previous comment.

Or if I added a blank line between this sentence and the previous one in this comment.

--Timeshifter (talk) 11:02, 14 December 2023 (UTC)

Yep, that's correct. Graham87 (talk) 15:04, 14 December 2023 (UTC)

TheDJ and Graham87. If a comment includes a table:

Caption text

Header text	Header text	Header text
Example	Example	Example
Example	Example	Example
Example	Example	Example

Are colons still OK to indent it? I am only talking about a table in a comment, not in an article.

I know I can add a left margin to get the same result, but does that even help accessibility?

And it is not easy to figure out the left margin size. For example with the 4 colons used to indent this comment I would have to use style="margin-left:6.4em;" for the left margin of the table. For example:

Caption text

Header text	Header text	Header text
Example	Example	Example
Example	Example	Example
Example	Example	Example

I don't remember editors doing this on talk pages.

--Timeshifter (talk) 01:11, 24 December 2023 (UTC)

@Timeshifter: Yeah colons are fine in situations like this. Graham87 (talk) 01:31, 24 December 2023 (UTC)

@Timeshifter: I can add to that. If a table is indented with colons (as in your first example), the list is continuous; but if an unindented table appears between two indented lines (as in your second example), there are now two distinct lists, and that is essentially a WP:LISTGAP problem. --Redrose64 🌹 (talk) 20:40, 24 December 2023 (UTC)

While the first table is indeed embedded within the list, examining the HTML shows that all of the nested lists are terminated afterwards and then a whole new set of nested lists started with the subsequent comment. I don't know how to avoid this; I tried out some methods but they didn't work. isaacl (talk) 19:57, 5 February 2024 (UTC)

The section to which you linked, Wikipedia:Manual of Style/Accessibility § Multiple paragraphs within list items, does not say using multiple colons to create paragraph breaks is not accessible nor generally one entry in the list should correspond to one comment. It is describing a way to have multiple paragraphs appear within one bulleted list item. Some users will use a bulleted list item followed by an unbulleted list item at the same nesting level. This causes extra list end/start announcements to be made by screen readers, which is inconvenient. isaacl (talk) 23:34, 24 December 2023 (UTC)

Another option I've been using for years is explicit <p>...</p> markup, just without line-breaking in the code. If you do :Yak yak yak.<p>Blah blah blah.</p> that makes a perfectly valid single list item of two paragraphs.

This line demonstrates.

With a paragraph break.

And another one. These will be read out as a single list item with multiple paragraphs.

Explicit <p>...</p> markup around the first part of the list item is not necessary. For large blocks of text you can use HTML comments to create visual line breaks in the code that don't exist in the rendered version and thus do not affect screen readers, like this:

This is paragraph 1 of a list item.

This is paragraph 2 of the list item.

This is paragraph 3 of the list item.

Markup like that is actually easier to read in complex blocks of wikisource material than using the {{pb}} template, though you can use the HTML comment trick with that too:

Start of new list item.

2nd segment of list item.

3rd segment of list item.

Using the explicit <p>...</p> markup is semantically better than {{pb}}, because the latter does not actually create paragraphs at all; what it does is inject an empty <div>...</div> that really serves no semantic function, specifically the following code: <div class="paragraphbreak" style="margin-top:0.5em"></div> It is nothing but visual spacing by injecting some CSS margin-top. An argument can be made (and probably argued against, from differing viewpoints about Web semantics) that actually just using <br /> (or <br />&nbsp;<br /> to inject a blank line that the parser does not automatically collapse) is semantically superior to {{pb}}, though inferior (for paragraphization) to <p>...</p>. The {{pb}} template is actually misnamed and misleading.  — SMcCandlish ☏ ¢ 😼  00:25, 30 December 2023 (UTC)

Strong tags

Hi! It has been my impression that in an ideal world, <strong>...</strong> should be used used instead of '''...''' to indicate bold emphasis. Is that correct, or can they be used interchangeably? HouseBlaster (talk · he/him) 01:24, 1 February 2024 (UTC)

My question is to screen reader users. Does the screen reader verbally announce the beginning and end of bolded text? Is that annoying? As a sighted reader I find that bolded text is helpful, but not essential. But if my reading of the text was interrupted by some audio or flashing light or whatever, then I would be annoyed.

Is it only certain bolded text that is announced by the screen reader? <strong>...</strong> versus '''...'''

Are top headers in tables announced as the bolded text that they are? Can that be turned off? What about row headers that are bolded (if not using class=plainrowheaders). Are these italics announced?

--Timeshifter (talk) 01:51, 1 February 2024 (UTC)

They don't read out any attributes like that. As the guideline says (and my experience confirms), "By default, most screen readers do not indicate presentational text attributes (bold, italic, underline, monospace, strikethrough) or even semantic text attributes (emphasis, importance, text deletion)". Graham87 (talk) 07:50, 1 February 2024 (UTC)

Column and Row headers are semantic and are represented (well mostly) by screenreaders, but the bolding they have is purely presentational. —TheDJ (talk • contribs) 09:17, 1 February 2024 (UTC)

The Wikicode that includes '''...''' isn't what's sent to the browser. It's converted to HTML, as <b>...</b>. So it's a b element rather than a strong element, but it certainly isn't '''. The point of Wikicode is that it take much less labor to write than does HTML, but it's HTML that gets sent to the browser. Largoplazo (talk) 11:13, 1 February 2024 (UTC)

I believe the original poster wasn't under the impression that the wikitext markup was being sent to the browser. Conventional web best practice is to use semantic markup rather than presentation-specific markup (with presentation being handled by CSS). The reality though is that elements such as <b> and <i> are widely prevalent on the web, so for better or worse, assistive technologies have to take this into account. isaacl (talk) 17:34, 1 February 2024 (UTC)

Regardless of the underlying technical details of how MediaWiki handles bold and italic markup, Wikipedia itself discourages them for emphasis anyway, so this is fairly moot. Chris Cunningham (user:thumperward) (talk) 07:12, 2 February 2024 (UTC)

If it's semantic emphasis, use <strong>...</strong> or the template wrapper {{strong}}, but per MOS:BOLD this should very rarely be done; use <em>...</em> or {{em}} in most cases instead. Whether screen readers right this second support this semantic markup very well is immaterial; it exists and is well-defined as serving this semantic purpose, and support will get better over time. What's never going to be helpful is using ''...'' (equals <i>...</i>), or '''...''' (equals <b>...</b>) where semantic emphasis is intended, because that is purely visual formatting with no semantic implications (e.g. italics around foreign terms or book titles, or boldface to mimic the bold keyword in a directly quoted definition that was boldfaced that way in the original source). Screen readers will ignore that non-semantic markup on purpose and are never going to change in that regard.

Technically speaking, <i>...</i> is directly equivalent to <span style="font-style: italic;">...</span>, and <b>...</b> is directly equivalent to <span style="font-weight: bold;">...</span>, with the short tags grudgingly retained, despite failing the separation of content and presentation, simply because their use is too convenient and ingrained. Use of these elements has no implication of importance or stress/emphasis. For more details, see the i and b element entries in the HTML5 spec [1], and contrast them with the em and strong elements [2]. According to the spec, nesting multiple instances increases stress level, though it is dubious whether any real-world applications support this yet (e.g. by increasing volume and/or pitch).

PS: Use of bold for pseudoheadings to avoid ToC entries should use '''...''' (equals <b>...</b>), since even real headings simply have boldface applied by CSS, not semantic stress. Using strong for that purpose would imply that the pseudoheading was the most or one of the most important things on the page, which is rather the opposite of the intent. And definitely don't abuse ; markup for this, per MOS:DLIST; that creates a bogus definition/description/association list, that has a term (the boldfaced item) but no definition/description/association.  — SMcCandlish ☏ ¢ 😼  10:11, 2 February 2024 (UTC)

So MOS:BOLD says it should rarely be done. And the semantic web is barely implemented and very problematic. And there is no button on the editing toolbar for strong tags, but there is one for bolding. --Timeshifter (talk) 02:47, 4 February 2024 (UTC)

MOS:BOLD says bolding should rarely be done. Am I correct that when bolding is done for emphasis, it should be done with <strong>...</strong>, not '''...'''? HouseBlaster (talk · he/him) 03:11, 4 February 2024 (UTC)

What purpose do strong tags really serve? The default settings for screen readers is to ignore it. Are we waiting for a future utopian semantic web that will probably never arrive? AI large language models seem to be working fine even though the vast majority of the web is not using semantic web coding. I notice you using em tags in your reply. Are we really going to encourage such preciousness for something I have yet to see serving any useful purpose? --Timeshifter (talk) 03:19, 4 February 2024 (UTC)

First, that is moving the goalposts. The purpose it serves is separation of presentation and content. AI large language models seem to be working fine even though the vast majority of the web is not using semantic web coding is irrelevant. AI also seems to be working just fine with all the typos on Wikipedia, but that doesn't mean we should encourage typos. I use em tags because they are the semantic markup for emphasis. HouseBlaster (talk · he/him) 03:31, 4 February 2024 (UTC)

If they serve no purpose, then why bother? People reading Wikipedia still see bolding and italics either way. Screen readers ignore em and strong tags in their default settings. AI works fine without it. Why do you even care? Very few people are going to follow you in this crusade. But you will annoy a lot of people by telling them they must use em and strong tags for basic article editing. Wikis were made for ease of use, and to not need the more arcane coding of HTML, etc.. We are trying to keep new editors, not drive them away with bizarre coding demands that serve no purpose. --Timeshifter (talk) 03:41, 4 February 2024 (UTC)

Please do not personalize the dispute. I just explained the purpose it serves: separation of presentation and content. I am not forcing you to avoid using '''...'''. But I am going to fix incorrect use of presentational markup for semantic emphasis, just like I would fix a typo. Rather than go back and forth, I will wait for others to respond because we are not going to convince one another. HouseBlaster (talk · he/him) 03:49, 4 February 2024 (UTC)

The page you linked (Separation of content and presentation) to has a single one-paragraph section of relevance:

Use in Web design

This principle is not a rigid guideline, but serves more as best practice for keeping appearance and structure separate. In many cases, the design and development aspects of a project are performed by different people, so keeping both aspects separated ensures both initial production accountability and later maintenance simplification, as in the don't repeat yourself (DRY) principle.

That is mainly about using external stylesheets over inline CSS. And so on.

It is not about applying em or strong tags on Wikipedia. They are applied individually, and they serve no special presentation purpose on Wikipedia, or in screen readers at default setting. The result looks exactly the same as editing-toolbar-applied bolding or italics. You have yet to show me how it serves any purpose in the real world. --Timeshifter (talk) 04:35, 4 February 2024 (UTC)

Timeshifter, the fact that you don't like to bother with the correct markup, and are impatient for more practical real-world utility for it, is immaterial. No one is required to "obey" the MoS to add material; all that is required is you not go around changing compliant markup to non-compliant markup or get in fights with people making noncompliant markup be compliant. If you just use bare/basic bold every time you add something new and some of it should be using strong, someone else will fix it later. MoS is primarily a WP:GNOME cleanup manual (and to the extent it's not, it a dispute-resolution manual, which resolves to "just follow the guideline")  — SMcCandlish ☏ ¢ 😼  00:46, 5 February 2024 (UTC)

It is not the first time I have seen a MOS or other guideline that serves absolutely no purpose. But this is the page for MOS accessibility, and so this is the page to discuss it. So you agree with me that it serves no accessibility purpose. Then the quideline at MOS:BOLD needs to be changed. It says: "This way, the words can stand out for text to speech and other accessibility softwares." That needs to be removed or clarified. Clarified with a link to the Graham87 diff that says the default settings for screen readers ignore it. That way, there will be fewer editors wasting their time adding useless strong tags. --Timeshifter (talk) 11:15, 5 February 2024 (UTC)

I've modified it, but tried to do so in such a way that the text won't go out-of-date so quickly. The text was originally added by Thinker78 in October 2022. Graham87 (talk) 15:40, 5 February 2024 (UTC)

Thanks Graham87. I suggest putting after semantic markup: (part of the semantic web, a pipe dream). And after "which may be used by screen readers and other accessibility software": (though nobody has been found using screen readers, etc. this way on Wikipedia, so don't waste your time adding strong and em tags. And it goes against making wiki coding simpler, not harder). But I think I may bow out of this discussion for awhile. There was something else that was spread around various help pages for years that was of a similar vaporware nature. I can't remember now what it was, but it disappeared. --Timeshifter (talk) 16:13, 5 February 2024 (UTC)

though nobody has been found using screen readers, etc. this way on Wikipedia. Regards, Thinker78 (talk) 19:46, 5 February 2024 (UTC)

In this dispute that started this thread, Timeshifter reverted me at Template:Sticky header/doc when I swapped use of '''...''' for <strong>...</strong> when the bolding was used for emphasis. I would appreciate it if someone could resolve our dispute at Template talk:Sticky header#Bolding. Best, HouseBlaster (talk · he/him) 01:00, 5 February 2024 (UTC)

HouseBlaster. I will not change your strong tags back to regular bolding, now that this discussion has sadly resolved in the favor of your current point of view. If you want to waste your time on this useless activity, then knock yourself out. In fact, after you completely convert all bolding to strong tags on a few help pages, you will have annoyed enough editors that this vaporware of the semantic web will be seen as contradictory to the simplicity that wikis were created for. Or maybe the Mediawiki developers will convert all bolding to strong tags in the HTML. And that way we can continue to use the much simpler method of bolding in the wikitext editing toolbar. --Timeshifter (talk) 16:23, 5 February 2024 (UTC)

<strong> is used for bolding with emphasis and <b> is used for bolding without emphasis (Mediawiki changes ''' to <b>). In the Sticky header template doc page example, if the intent is to emphasize the sentence, use <strong>, and if the intent is not to emphasize the sentence, don't use any bolding at all. I see no case where we'd use <b> (aka ''') for that sentence. Levivich (talk) 19:34, 5 February 2024 (UTC)

The discussion here has come up at a policy page, in WT:Banning policy#Semantic markup. Whether or not the way that the vast majority of editors edit presents an actual accessibility problem is something that I don't have the expertise to really understand, but I think it is likely that there will be a lot of pushback against implementing such changes, without first getting widespread community buy-in. --Tryptofish (talk) 21:25, 12 February 2024 (UTC)

When are tables an accessibility problem?

I'm involved in a dispute where Thumperward has removed tabular versions of information in Endianness arguing that a written description is adequate and the tables are an accessibility problem. There are a few other issues in play but please refer to the end of this discussion for the main points.

Is there really an accessibility problem with standard tables like this? Do we really discourage using tables where prose can be used instead or is it OK to include both appreciating that a bit of repetition in different formats is helpful for many readers. ~Kvng (talk) 15:58, 1 February 2024 (UTC)

Specifically, the context is the use of HTML tables to draw diagrams like those shown here and here. These aren't data tables, and they aren't even being used for positioning: they're just illustrations built out of boxes. Chris Cunningham (user:thumperward) (talk) 16:03, 1 February 2024 (UTC)

If the problem is HTML vs. Wiki I think I've already proposed we can do any necessary behind-the-scenes formatting changes to address accessibility technical issues. Tables like these are used frequently to illustrate data layout in packets and memory e.g. User_Datagram_Protocol#UDP_datagram_structure. Would you propose to remove these too? ~Kvng (talk) 17:21, 1 February 2024 (UTC)

Yeah that table makes no sense to me on my screen reader JAWS. I don't want to get involved in this much further though. Graham87 (talk) 18:06, 1 February 2024 (UTC)

Common use is not an argument for anything more than widespread ignorance. I would certainly argue to remove other bad tables. "HTML vs wiki" is meaningless; wikicode is rendered as HTML. Chris Cunningham (user:thumperward) (talk) 07:05, 2 February 2024 (UTC)

The columns are successive byte addresses, and the rows show different interpretations of the stored bytes. Appropriate headings for the columns and rows should be able to clarify this. isaacl (talk) 18:57, 1 February 2024 (UTC)

This is like saying that a PNG is a succession of hue and brightness values and that with appropriate table headings serves as an appropriate way to describe an apple to the unsighted. Chris Cunningham (user:thumperward) (talk) 07:07, 2 February 2024 (UTC)

Tables are in fact commonly used in format specifications to describe how the bits and bytes are laid out (and not to describe the appearance of the data being stored). isaacl (talk) 08:59, 2 February 2024 (UTC)

It's a perfectly good visual representation of the concept that it illustrates, but in web terms it's awful because in HTML terms it's badly constructed and because it's inaccessible by screenreaders. The only options I can think of are

• Describe the matchup between bytes and words very well in the text and then, on the table tag, add an aria-label stating "A table providing a purely visual representation of the ... explained above." But that's still off-putting use of HTML and still subjects the screenreader user to sitting through the mumbo-jumbo to get to what's after it. Though maybe that could be resolve by supplying a screenreader-friendly Skip link.
• Replace it with an image and supply suitable alt text. After all, nobody benefits from it being cobbled out of HTML.

Largoplazo (talk) 22:58, 1 February 2024 (UTC)

Anything that makes an article clearer through illustration or tables, or combinations thereof, are a good thing in my mind.

If the table-diagram would serve this purpose as an image, but unfriendly table coding is used instead, then I think your idea is good: "a screenreader-friendly Skip link."

Table coding may be easier to edit for many people than image editors. So whatever is easiest. If there is a choice use the better illustrative final result. That can change. Put the various versions on the article talk page so others can further improve either format (image or table coding).

--Timeshifter (talk) 23:30, 1 February 2024 (UTC)

I think with the addition of appropriate column and row headings, the meaning of each cell will be discernable. It's not a lot different than how protocols or file formats are described in specification documents, and those use tables. (For a Wikipedia example, see Transmission Control Protocol § TCP segment structure.) isaacl (talk) 23:37, 1 February 2024 (UTC)

I'm no expert but it seems unlikely to me that headings will make any difference. It's the visual experience of the juxtaposition that makes the illustration effective. But, for sighted readers, it's a supplement, not the primary explanation, anyway. Graham87, who is blind, didn't seem hopeful in his comment above. Largoplazo (talk) 23:46, 1 February 2024 (UTC)

As I alluded to, endian layouts in protocols have long been displayed in tables. It's much more effective than describing data formats in prose. isaacl (talk) 00:01, 2 February 2024 (UTC)

We need a template for a "a screenreader-friendly Skip link." Preferably one that is only seen by the screen reader. --Timeshifter (talk) 00:05, 2 February 2024 (UTC)

All commonly used screen readers have keystrokes/actions for moving to the end of a table, moving to the next table, etc. We don't need a skip link. Graham87 (talk) 05:14, 2 February 2024 (UTC)

Nobody is arguing that ignoring the needs of others is not more efficient. Technical articles full of this sort of thing are usually dreadful anyway, and that especially applies to our networking articles (which are written exclusively by and for people who already understand the subject). Chris Cunningham (user:thumperward) (talk) 07:17, 2 February 2024 (UTC)

@Kvng, if the idea of constructing a vector diagram seems daunting, you could make a screenshot of the "ASCII art" and upload that as a bitmap image. It'll still be as useless as any other photo to people using screen readers, but the objections about misusing table formatting would evaporate.

Wikipedia:Screenshots of Wikipedia suggests zooming in as much as you can. (If you created the table originally, then all the copyright in that page steps are irrelevant.) WhatamIdoing (talk) 00:22, 2 February 2024 (UTC)

Kvng, HTML elements have defined semantics that differing presentation modes for documents (such as screen readers) are supposed to be able to rely on or expect. A table in HTML is supposed to be just that. While any accessible software inevitably has some work dedicated to cleaning up behind the scenes when documents don't adhere to the standard, it is still broadly an issue for accessibility—even if considered to be more or less so according to how concrete or obvious it is to any given individual. — Remsense诉 00:24, 2 February 2024 (UTC)

MOS:LTAB should be relevant. "Avoid using tables for visual positioning of non-tabular content..." Jroberson108 (talk) 00:27, 2 February 2024 (UTC)

I don't understand MOS:LTAB. I don't think just the addition of role=presentation will warn off a screen reader user to the equivalent of "there be dragons here", and so ignore this. I looked online elsewhere about it, and can't see how it would act as "a screenreader-friendly Skip link."

As a last resort, a screenshot can be taken as previously suggested, and uploaded to the Commons. I use freeware Irfanview for such stuff since it can save the image as a compressed PNG image (for low kilobytes). --Timeshifter (talk) 01:48, 2 February 2024 (UTC)

The role="presentation" is used to hide the element from the accessibility tree. You can read more at hiding-semantics. For relevance, tables are mentioned twice on that page. Jroberson108 (talk) 04:01, 2 February 2024 (UTC)

Jroberson108 and others. I don't understand that stuff. Can you tell me if there is a way to tell a screen reader that an upcoming table will not be accessible? Graham87 said: "All commonly used screen readers have keystrokes/actions for moving to the end of a table, moving to the next table, etc. We don't need a skip link." But the screen reader user shouldn't have to waste time trying to figure out an inaccessible table before giving up and moving to the end of the table. They should be warned. I guess some text could be added in front of the table such as "Inaccessible table". A way is needed to present that text just to the screen reader user. I don't think it is a good idea to convert tables to screenshots unless absolutely necessary. Having to upload a new version of a table screenshot over the old version for every little change is more work. --Timeshifter (talk) 13:26, 2 February 2024 (UTC)

No, that would be extremely jarring and would be ramming an opinion down people's throats. Maybe *some* screen reader users might find it marginally useful, for some reason (especially if they're visually impaired and using a screen reader along with a screen magnifier, say). There is some advice about making a screen reader detect a table as a layout table rather than a data table in the accessibility guideline, but that really wouldn't help here. Graham87 (talk) 15:15, 2 February 2024 (UTC)

I'm fine with "screenshot with appropriate accompanying text" as a solution here, though to be honest I tend to skip the screenshot. The question is not really about what alternatives are available so much as clarifying that the examples presented are not considered an accessible way to present the information, which this discussion already seems to have validated. Chris Cunningham (user:thumperward) (talk) 07:05, 2 February 2024 (UTC)

I would agree with doing these as images, since they really are illustrations cobbled together with HTML markup and are not actually data tables. This could be done using a sandbox page to fine-tune the result and get the best screen-shootable version (perhaps by making it substantially larger, so the resulting image is higher resolution than than a typical wiki table at an average font size).  — SMcCandlish ☏ ¢ 😼  09:33, 2 February 2024 (UTC)

Rather than using an image, I think it would be better to convey the information in a data table. For instance:

Storage of a 32-bit integer, 0x0A0B0C0D, on a PDP-11

byte offset	8-bit value	16-bit little-endian value
0	0Bh	0A0Bh
1	0Ah
2	0Dh	0C0Dh
3	0Ch

isaacl (talk) 17:42, 2 February 2024 (UTC)

That removes the problem of the abuse of semantic HTML. But re accessibility, won't a screen reader read this is something like "byte offset 1 8-bit value 0bh 16-bit little-endian value 0a0bh byte offset 1 8-bit value 0ah 16-bit little-endian value 0a0bh" etc.? It seems as though it will fail to convey the point it's meant to convey.

I don't know for sure, but it always strikes me that the use of spans for anything other than creating a header hierarchy from left to right (or right to left in rtl scripts) or top down is inaccessible and, in an actual data table (though I don't see it as a problem here), pointless. Largoplazo (talk) 18:07, 2 February 2024 (UTC)

A horizontal layout would probably make the relationships more clear for screen readers reading in the inline direction:

Storage of a 32-bit integer, 0x0A0B0C0D, on a PDP-11

byte offset	0	1	2	3
8-bit value	0Bh	0Ah	0Dh	0Ch
16-bit little-endian value	0A0Bh		0C0Dh

isaacl (talk) 18:27, 2 February 2024 (UTC)

I actually like the first one better, but I don't know exactly why ... screen readers also have table navigation commands for moving by row or column. Graham87 (talk) 06:45, 3 February 2024 (UTC)

I'm back. I don't see discussion of Thumperward's assertion that the tables should be removed because the layout is already described in prose. Instead, there are suggestions about how these can be composed or rendered in a more screen-reader-friendly way. I learned that screen readers have a skip feature so if these tables aren't helping, they aren't too much in the way.

There was a suggestion to render these as bitmap or vector images and use ALT to describe them. It is easier for editors to maintain the table markup. Is there a way to add an ALT to a whole table? ~Kvng (talk) 23:48, 4 February 2024 (UTC)

Not really, anymore, since the summary attribute is obsolete in HTML5, per Help:Table § Captions and summaries. It's possible to use {{sronly}} with a caption though to make all or parter of it only read by screen readers. But in this case, one of the above two examples of a fixed-up version of the table would suffice. I'd say. Graham87 (talk) 03:33, 5 February 2024 (UTC)

There is broad recognition that these tables are not useful to those using screen readers. It has been suggested that the tables be replaced with images but this would not help editors and there is not a consensus that this would help readers. I don't see anyone supporting Thumperward's assertion that tables (or images) should be removed if the material is already explained in prose. In general, the Wikipedia way is to improve, not delete problematic content so I am inclined to revert Thumperward's deletions while anyone interested works on improving this. ~Kvng (talk) 21:55, 9 February 2024 (UTC)–

Kvng. Why wouldn't image versions of an inaccessible table help readers? They look exactly the same. --Timeshifter (talk) 22:27, 9 February 2024 (UTC)

The point I was trying to make is it is not clear that converting the tables to images would help readers. Sighted readers would see the same thing. Those using screen readers would either skip an image or a table; neither seem to be of help to them. ~Kvng (talk) 03:14, 10 February 2024 (UTC)

And I've said several times that I have no problem with converting these tables to images and including them that way, with adequate captions and alt text. Indeed there are already comparable illustrations of this sort available. If you're looking for a compromise with broad consensus, then there it is. Declaring an intent to simply revert to your preferred version is quite different. Chris Cunningham (user:thumperward) (talk) 12:06, 10 February 2024 (UTC)

@Thumperward, I'm not looking for compromise with you personally, we're seeking WP:CONSENSUS among involved editors. Do you agree that images are more difficult for editors to maintain? If so or in any case, I assume you believe this potential disadvantage is outweighed by an accessibility improvement. I don't have screen reader experience but Graham87 has reported that tables and images can both be readily skipped when using a screen reader. ~Kvng (talk) 13:48, 10 February 2024 (UTC)

Kvng. People using screen readers shouldn't have to waste time first trying to decipher an inaccessible table before they skip the table. So if you can't make the table accessible, then convert it to an image until you are able to make it accessible. See Wikipedia:Manual of Style/Accessibility/Data tables tutorial. --Timeshifter (talk) 14:01, 10 February 2024 (UTC)

@Timeshifter clearly there's a tradeoff to be made here between accessibility and maintainability. I don't see any discussion of converting tables to images in the MOS page you link (Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Images_and_color is about images in tables, not images of tables). I have not seen this conversion done in practice by editors. I have seen the reverse with editors justifying the table as more easily maintained (and no discussion of accessibility). ~Kvng (talk) 14:19, 10 February 2024 (UTC)

That is about icons mostly. That is not about what we are talking about.

About a table image: It just takes a little longer with an image if you decide to change it. But once an image is the way you want it to be, then there is no more work involved. So do all your work in a personal sandbox. I have hundreds of sandboxes. I keep the ones that are linked to discussions. See my user page: User:Timeshifter#Archives, subpages, etc.. Open the subpage index. If you keep a sandbox for each table, then it is easier to come back to it later, and do more work on it. Months, even years later. Screenshot it, and upload it over the old version. But it is even easier to just learn how to make the table accessible, and then everybody is happy. --Timeshifter (talk) 14:39, 10 February 2024 (UTC)

I want everybody to be happy but there doesn't seem to be consensus (at least not in this discussion) about what it takes to make these tables accessible. ~Kvng (talk) 14:48, 10 February 2024 (UTC)

You can't. HTML tables are designed to present tabular data (it's, erm, in the name) and their misuse to draw boxes is discouraged. That's the whole story. Nobody has said otherwise.

With regards to maintainability: if these tables were being regularly edited for some reason then that might be something which would warrant some other approach (maybe using Lua to dynamically regenerate them from wikicode). But they aren't: these diagrams are rarely edited (what with them being so finicky) and most of them were put in place well over a decade ago and left to rot. Another reason to bin them, as including complicated code in articles discourages inexpert readers from improving them. Chris Cunningham (user:thumperward) (talk) 22:40, 10 February 2024 (UTC)

I guess you can try to make a case for no need for maintenance here but then you go on to say they have been "left to rot" which implies otherwise. In any case, there are many other similar tables in networking and computing articles where more maintenance is performed. Do we do some with tables and others with images based on anticipated maintenance needs? IME trying to anticipate future changes is folly.

I don't like the idea of giving up and deleting things because it's too hard to do a good job for both normal readers and screen readers. That can't be right, can it? ~Kvng (talk) 02:27, 11 February 2024 (UTC)

@Kvng: All I said was "All commonly used screen readers have keystrokes/actions for moving to the end of a table, moving to the next table, etc." As it happens images aren't hard to skip either, but I thought that was worth clarifying. Graham87 (talk) 16:02, 10 February 2024 (UTC)

This is being deliberately obtuse. Multiple people have highlighted the problems with table diagrams. Nobody has supported your assertion that they are a positive improvement. You're trying to make articles worse for the sake of winning an argument on a technicality. Don't do that. Chris Cunningham (user:thumperward) (talk) 22:05, 9 February 2024 (UTC)

Thumperward. Isaacl found a way to improve some tables enough to get Graham87's approval.

Several people said tables like these help illustrate points in the related articles.

And almost everybody says that when tables can't be made accessible, then images can be used.

--Timeshifter (talk) 22:27, 9 February 2024 (UTC)

@Thumperward, at your request, I've spent a lot of time trying to engage others and work through this one issue productively with you. Please don't assume I have a goal other than to improve Endianess (and learn about accessibility issues). ~Kvng (talk) 03:18, 10 February 2024 (UTC)

I'm not sure to what you are referring when you say "these tables". I disagree that there is broad recognition that tables with appropriate column and row headings are not useful to those using screen readers. I think presenting endian information in tables is natural for both those who can see the table layout and those who can hear it being read, and thus tables would be preferable to images. isaacl (talk) 22:58, 9 February 2024 (UTC)

@Isaacl I'm sorry if I missed that point. Are you saying adding your proposed headings somehow render these legible by a screen reader? Has anyone (else) tested this? ~Kvng (talk) 03:23, 10 February 2024 (UTC)

I'm not exactly sure when you say "legible by a screen reader" if you mean whether the screen reader will read the table, or if someone using a screen reader will be able to understand what they hear. Screen readers will read tables, but if the table doesn't have headings, the screen reader won't be able to provide this context when reading a cell. With headings, it can announce this info when reading a cell. Yes, the examples I provided have been tested by someone, as you can see in the earlier discussion. Part of the point of having accessibility guidelines, though, is that following them will generally produce useful results, without having to continually round up test groups (which as mentioned in another thread, is tedious if the same person is going to get polled for every single possibility). isaacl (talk) 05:12, 10 February 2024 (UTC)

@Isaacl, we're trying to determine which is more accessible, images or tables. A screen reader would give caption and alt text for an image. Would it give something better than that for tables with your proposed headings? ~Kvng (talk) 13:54, 10 February 2024 (UTC)

A table provides interactive navigation of the data: a user can move from cell to cell, with the screen reader announcing the position (including heading info) and the cell contents. It has a caption, too. Alternate text for an image provides one static message, and would not allow the user to explore the interpretation of a given byte or pair of bytes at a particular byte offset. isaacl (talk) 17:55, 10 February 2024 (UTC)

Tables also generally scale better than images with using different page zoom levels, as the browser can use larger or smaller font sizes instead of using an image resizing algorithm, so this is more accessible for those who change the zoom level. Although it's not a significant issue for this table, browsers can alter the table layout as appropriate with browser window size changes, which also improves legibility and thus accessibility. isaacl (talk) 18:08, 10 February 2024 (UTC)

Good points. Accessibility is not only about screen readers, it is also about zoom. ~Kvng (talk) 02:30, 11 February 2024 (UTC)

Kvng. See: Talk:List of countries by intentional homicide rate. See the note at the top: "Note: Table updating info: /LibreOffice Calc instructions and /Excel instructions." Those are talk subpage links. You might use talk subpages to park tables to work on continuously over the years. Tables that are accessible can be copied to the article. Screenshots can be taken of inaccessible ones. Tables that are neither inaccessible nor understandable can stay in the subpage for further work by whoever is interested over the years. This method is not effected by talk page churn and archiving. Stuff stays in place. You can have multiple subpages. --Timeshifter (talk) 01:12, 13 February 2024 (UTC)

@Timeshifter: If I were you I'd put such a note in a template like {{notice}} (or whatever looks good), just so semi-automated/automated scripts like AWB general fixes don't add an "Untitled" heading to them. Having non-template text before the first header of a talk page is highly non-standard. Graham87 (talk) 09:52, 13 February 2024 (UTC)

Thanks Graham87. I tried it but it blends in too well with the wall of other talk table/banners, so it is not noticed. I will be using it elsewhere though. I haven't had any problems with WP:AWB since it is manually operated, and it is obvious that the note needs no change. I haven't seen a problem on multiple talk pages. I would like a template like Template:See also but for notes. Its indentation doesn't seem to bother people using screen readers, I believe. And it has no background color, and doesn't take up so much space like {{notice}}. --Timeshifter (talk) 20:15, 13 February 2024 (UTC)

@Timeshifter: I actually have found this sort of thing causing problems on several talk pages (I don't have an example to hand right now, but I often do talk page archiving/cleanup). AWB isn't always manually operated (see Wikipedia:Bots/Requests for approval/BattyBot 21, for example). Graham87 (talk) 03:10, 14 February 2024 (UTC)

Graham87. Ah yes, the upcoming battles against our AI bot overlords globally in auto mode. Just kidding. I guess I will take my chances. They haven't covered the talk pages I am talking about in auto mode in any detrimental way yet. And I can always fix it if they do. I found this related info: Help:Talk pages#Subpages and archiving.

--Timeshifter (talk) 16:14, 14 February 2024 (UTC)

@Timeshifter: You're not going to live forever and you won't be on Wikipedia forever either. I would strongly recommend using *some* sort of template to note the subpages for the sake of long-term standardisation. Also, that help page you linked contains some really old cobwebs ... including the bit you were probably referring to which I've boldly removed. I referred back to this talk page at Help talk:Talk pages#Note about subpages. This conversation is probably getting way off-topic for here. Graham87 (talk) 17:01, 14 February 2024 (UTC)

Graham87. I looked around hard for a template I could use, but couldn't find one. When I do find one I will use it. --Timeshifter (talk) 18:37, 14 February 2024 (UTC)

FWIW I think using {{notice}} is a good and appropriate suggestion. What you have there now is likely to get swallowed at some point by an archiver or editor doing cleanup. ~Kvng (talk) 00:43, 15 February 2024 (UTC)

Using subpages is a good suggestion if this is the way it needs to go. This would help current and sufficently determined editors make changes. It doesn't quite fulfill the "Encyclopedia anyone can edit" objective. ~Kvng (talk) 15:00, 13 February 2024 (UTC)

Correct me if I've misread but I don't see any sustained support for not including these tables. Although it remains to be decided whether they should be rendered as images or HTML tables, I think it is now appropriate to restore the tables to Endianness while we work on accessibility improvements. ~Kvng (talk) 15:06, 13 February 2024 (UTC)

I've already presented how to make one of the tables accessible by adding a caption and headings with scope attributes. Including these will bring the tables into alignment with best practices for accessibility. isaacl (talk) 18:44, 13 February 2024 (UTC)

I'm honestly not entirely opposed to your suggestion - it does indeed solve the issue by making this a tabular display of content instead of an illustration. Whether it truly clarifies anything in the article is another matter, but that's more of a style issue. Chris Cunningham (user:thumperward) (talk) 08:53, 15 February 2024 (UTC)

Bad-faith reverts

This was very obviously not a result of the above discussion, but instead a lawyerish move to win an argument based on an obtuse interpretation of what is and is not forbidden. The result is terrible and should be removed again. Chris Cunningham (user:thumperward) (talk) 23:47, 17 February 2024 (UTC)

@Thumperward, what do you take as the result of the above discussion? ~Kvng (talk) 01:41, 18 February 2024 (UTC)

The single conclusion which cannot possibly be drawn is "the table was fine as-is, put it back in". Literally nobody except you has advanced this.

Given that this is a style guide discussion page and not a courtroom there was not a single decision that was rounded on by everyone. However, the following positions were all given weight:

• Tables should not be used merely for style;
• If data is being presented in a table, then the use of features such as headings, labels and captions is strongly encouraged;
• For purely illustrative purposes, an image produces results which are no less accessible than tables full of line art.

In the interest of compromise (and let's be clear here: I did this twice, whereas your "compromise" was to revert directly to your preferred version from pre-discussion), I made two suggestions: either use an image, or use the tabular format Isaacl suggested here. Either would be a significant improvement. Chris Cunningham (user:thumperward) (talk) 11:16, 18 February 2024 (UTC)

isaacl has since improved the tables after my revert. I beleive we're where we want to be for this table. I encourage you to hep us get there with the others. It was always my intent that the tables be improved. I said above I think it is now appropriate to restore the tables to Endianness while we work on accessibility improvements. My idea was it would be easier to improve incrementally from what you deleted than to recreate from scratch. isaacl seems to have misunderstood this too and I'm sorry if I wasn't clear. ~Kvng (talk) 13:58, 18 February 2024 (UTC)

No, I fully understood what you proposed. I responded on your talk page with my view that you shouldn't revert back to the previous version since the discussion had already been started on how to improve the tables. Multiple people have pointed out in this discussion the advantages of having headings. Each time you spoke about restoring the previous version, I highlighted how instead a more accessible version can be added. I'm disappointed you chose to proceed with your revert. isaacl (talk) 18:16, 18 February 2024 (UTC)

That discussion was two weeks ago. It was good advice when this discussion was in its early stages and I heeded it. You said I favour seeing what consensus can be found before changing the article again. Twice above I asked if we had consensus and when it seemed we did, I waited another couple of days before taking first steps to implementing it. Again, it was never my intent or position that we should restore the removed material and leave it at that. I restored the material so that you could apply your improvements to it. ~Kvng (talk) 18:41, 18 February 2024 (UTC)

Not sure why you keep repeating your intent; as I said, I understood fully. You participated in the discussion regarding the accessibility advantages, and I created the wikitext markup for you so you could have easily copied it over. Twice after you asked about reverting to the original version I pointed out the accessible version. It would have been ideal to have worked collaboratively on improving the table, which you said you wanted to do, rather than not making use of the provided improvements. isaacl (talk) 22:57, 18 February 2024 (UTC)

So you both are unhappy I reverted and then we improved the tables rather than (me?) adding fresh improved ones based on isaacl's work. Sorry about that. There is still another set of tables that needs to be restored/added. Thumperward has indicated that he's unwilling to help with this. How do we want to proceed? ~Kvng (talk) 14:29, 19 February 2024 (UTC)

Note I do not support your re-adding the previous version of the table into the article. This remains the case even if you post about it again and I don't respond. I'm not sure of the best way to discuss how character bytes packed into an integer are affected. The heading "Byte addressing" doesn't seem apt. At some point I might try to consider ways to improve the current text. isaacl (talk) 19:02, 19 February 2024 (UTC)

Kvng and Isaacl. In the meantime the tables can be parked in talk subpages until they are made accessible and understandable. I found that the generic hatnote template works for notes at the top of talk pages. Template:Hatnote. Graham87 or others, please tell me if the following notes are accessible. The links work when the notes are looked at from the talk pages.

Note: See table updating info: /LibreOffice Calc instructions and /Excel instructions.

Note: Technical users please see /Table creation code for useful code related to updating tables with scripts.

Talk pages:

• Talk:List of countries by intentional homicide rate
• Talk:List of U.S. states and territories by intentional homicide rate

--Timeshifter (talk) 16:12, 26 February 2024 (UTC)

There is no need; the table in question is available in the page history. isaacl (talk) 18:12, 26 February 2024 (UTC)

The subpage acts as a sandbox for experimentation, continual improvement, links, notes, discussion, etc.. Editors can get up to speed faster if they can go to one place. Stuff rolls off talk pages. Editors change. --Timeshifter (talk) 18:29, 26 February 2024 (UTC)

Future editors are not bound by what was done in the past. They can determine from scratch if a different presentation of the data would offer greater advantages than the current prose. Changing editors is good for new ideas. isaacl (talk) 18:43, 26 February 2024 (UTC)

I agree. Editors can use, or not use, what was done in the past. That is the way I operate. It is nice to know what has been tried already, too. Why reinvent the wheel. Saves a lot of time and grief. Makes it easier to try out new ideas. And/or to fix what was broken. If someone parks a table in a subpage, then someone else, even years later, may be able to fix it. I fix and update lots of tables. --Timeshifter (talk) 20:23, 26 February 2024 (UTC)

I've moved the notes above the table of contents because screen reader users like me won't notice them otherwise and made the subpage names absolute. I agree that these will get much use in the medium to long term though and they might be eventually discarded at MFD. Graham87 (talk) 04:41, 27 February 2024 (UTC)

Can you please move your discussion of other pages to another, more appropriate thread? isaacl (talk) 04:59, 27 February 2024 (UTC)

Kvng said he might use this idea. Graham87 asked for a template for these subpage notes. You asked that Kvng not repost inaccessible tables. Thumperward did not want bad-faith reverts. This allows Kvng to save those tables without reposting them. Moving this thread elsewhere would remove this solution from other editors with the same problem. --Timeshifter (talk) 14:16, 27 February 2024 (UTC)

This particular subsection is about one article. You've asked for feedback on some changes you made to other talk pages, thus hijacking this thread. Please separate this request into a separate subsection. isaacl (talk) 17:56, 27 February 2024 (UTC)

Colon versus margin

See Template:Sticky header/doc#Standard usage.

See diff. Pinging Houseblaster. HouseBlaster

The wikitext table at the top of that section is indented. Is there any problem with using a colon for that? Is a margin better?

See related discussion higher up: #Paragraph breaks in a comment. Scroll down for margin info. --Timeshifter (talk) 19:12, 5 February 2024 (UTC)

@Timeshifter: My username has a capital "B", so I didn't get that ping (lowercase-b Houseblaster is a doppelganger account). Colons create description lists (which we use on talk pages even though it is incorrect). margin-left is the CSS for indenting. HouseBlaster (talk · he/him) 19:19, 5 February 2024 (UTC)

See also higher up: #single-item lists

I think #Paragraph breaks in a comment contradicts you. Scroll down for the margin info.

Pinging people from that discussion:

SMcCandlish. Graham87. isaacl

--Timeshifter (talk) 19:44, 5 February 2024 (UTC)

The initial portion of the section on paragraph breaks in a comment is unrelated, as it is about successive list items, which does not fit the scenario in question. The later portion was within the context of embedding a table within a list. There isn't a reason to place the table in question within a list, and so there's no content-related purpose to prefixing it with a colon. Spacing for appearance is best done using CSS. isaacl (talk) 19:50, 5 February 2024 (UTC)

My question is whether using a colon for this is forbidden. And why. It is a lot simpler to use a colon. Versus creating a div with a margin. Or having to do the math to get multiple colon equivalents.

Why should editors have to go to all this trouble for a single wikitext table? Is it really bothering anybody? Even people using screen readers. And see the related section higher up: #single-item lists

See the "Standard usage" section of this version of the page to see the wikitext table indented by a colon. Hopefully someone with a screen reader can look at it too.

--Timeshifter (talk) 20:04, 5 February 2024 (UTC)

Timeshifter, using a colon in that instance is not "forbidden", but it is something that should be fixed. In the single-item lists section above, Graham87 confirms that is an annoyance to have a single-item list when there is not an actual list. — HouseBlaster (talk · he/him) 20:10, 5 February 2024 (UTC)

HouseBlaster. Graham87 wrote: "As a screen reader user, not really ... it's slightly annoying but not unusual at all and certainly not the end of the world". So I don't think it is a big deal. --Timeshifter (talk) 21:30, 5 February 2024 (UTC)

SMcCandlish's reply in a previous thread applies. Sure, you can enter whatever markup you like, but someone may change it to comply with guidelines upon which the community has agreed, and you shouldn't argue with other editors about the specific change. Regarding changing the guidelines so that colons are used as indents instead of list items, based on past community discussions, it doesn't favour this change. Editors prefer that the generated HTML output appropriately reflects the semantics of the page. To do this semantically would require changes to MediaWiki, and there would be a large backwards compatibility problem to resolve. isaacl (talk) 20:21, 5 February 2024 (UTC)

I have no idea what you are talking about concerning the generated HTML effecting anything that matters. I am not arguing. I just don't understand. So until I see how it effects anything that matters I will follow SMcCandlish's advice to ignore it all, and go on as before, and let the gnomes continue fixing stuff that doesn't seem to matter. --Timeshifter (talk) 21:30, 5 February 2024 (UTC)

... fixing stuff that doesn't seem to matter = "Stuff that I'm being told by people who know what they're talking about does matter, but since I don't understand it I'll just stick my fingers in my ears and sing 'lalala' and not worry about the trouble I'm causing my collaborators here nor some of the readers because defiance and lack of collegial cooperation make me happy." Largoplazo (talk) 22:39, 5 February 2024 (UTC)

Note in a collaborative project, it's not necessary for every single volunteer to be convinced regarding project guidelines. It's fine not to understand. But an absence of understanding, or a disagreement regarding rationale doesn't exempt a community member from needing to be co-operative. isaacl (talk) 22:47, 5 February 2024 (UTC)

I am following your advice to follow SMcCandlish's advice. And I am ignoring Largoplazo. I have long ago learned that the "experts" on Wikipedia are sometimes wrong. So unless something makes sense, I don't work in that area. There is plenty of other stuff to do. Wikipedia is done by volunteers. I only volunteer where things makes sense. Or I am helping them make sense. Like on some help pages that interest me. --Timeshifter (talk) 23:05, 5 February 2024 (UTC)

Because the colon approach produces garbage HTML in a situation where the HTML matters, even if it's irrelevant to the page's visual appearance. Nobody ever said producing a proper result doesn't require effort. Largoplazo (talk) 20:51, 5 February 2024 (UTC)

@Timeshifter: in light of the unanimous opposition to this edit, would you please undo it in the spirit of consensus? Best, HouseBlaster (talk · he/him) 20:55, 5 February 2024 (UTC)

Feel free to change it back. --Timeshifter (talk) 21:30, 5 February 2024 (UTC)

See MOS:INDENT. Yes, there is a problem with using a colon as a visual indenter; it only has that effect incidentally, and is the incomplete second half of a description/definition/association list (MOS:DLIST). Abusing : just to generate visual indentation generates bad markup and for screen readers announces a "list" that is not a list. If you need to visually indent something in an article, use {{block indent}} or one of the alternatives. We seem to be stuck with this awful : habit on talk pages, but it shouldn't be done in article content or in internal documentation. The fact that one screen-reader user is used to the effect and not personally bothered by it is immaterial; this is about best practices, not doing poor practice just because we think we can get away with it. Screen readers are also not the only parsers for which it matters; any WP:REUSE of WP content may have completely different CSS that is not choosing to present a DLIST as a boldfaced term with an indented description/definition/association (such display is certainly not required or even suggested by WHATWG or W3C's HTML5 specs; it's quite arbitrary). PS: The fix for talk pages is pretty obvious (stop treating : as <dd> unless it is preceded by ; for <dt> (immediately or with another intervening :), but instead as a CSS-tweaked unordered list item that isn't bulleted, when used in series; or as simply a CSS-indented <span>, when used alone and forming no list of any kind), but the devs have never implemented it for some reason.  — SMcCandlish ☏ ¢ 😼  00:02, 6 February 2024 (UTC)

It doesn't affect the Windows screen reader I personally use, JAWS, unless ordered/unordered lists are added into the mix as well, but it does affect NVDA, which is just as commonly used on Windows these days. Graham87 (talk) 07:19, 6 February 2024 (UTC)

Is this collapsible table accessible?

This was at the bottom of this section: Help:Collapsing#Tables with captions

I pulled it out of the wikitext/result pair, and placed it here just below. Is it accessible? Someone said it wasn't.

A longer table caption needs to wrap for cell phones, etc.
Name Score John 59 Bob 72

Here is the wikitext/result pair and intro below. That is the format used on that page. We discussed that format here:

• #Are these nested tables accessible?

Here is a method that allows the overall table header to wrap anywhere as needed. It is using a column header in the wikitext instead of caption wikitext. It is basically a wrapper. Any table can be placed inside without alteration.

Code entered	Output produced
{| class="wikitable mw-collapsible mw-collapsed" |- ! A longer table caption needs to wrap for cell phones, etc. |- | {|class="wikitable" ! Name !! Score |- | John || 59 |- | Bob || 72 |} |}	A longer table caption needs to wrap for cell phones, etc. Name Score John 59 Bob 72

--Timeshifter (talk) 11:19, 6 February 2024 (UTC)

Captions go in the caption element; header information goes in a th element. You're making a pseudo-caption using a hacked th element. This is an accessibility issue. You're using a wrapper table solely for the purpose of collapsing the tale nested inside it. This also is an accessibility issue. --Redrose64 🌹 (talk) 18:14, 6 February 2024 (UTC)

Well, I would like someone with a screen reader to tell me what the screen reader says about it.

Help:Collapsing has various methods to make the top text show up. Sometimes it's text in a data cell. Sometimes it's a row of header cells at the top. Sometimes it's a caption at the top. I have no idea if any of those examples are accessible.

And I didn't write that help page. I just found this method above somewhere, and noticed it solved the wrapping problem in the "Tables with captions" section. So I added it.

Stuff like this is used on user pages too, so it does not have to meet the highest standards. So I wonder if the other collapsible tables there are accessible too. That would be good info to add to the page.

And not all nested tables are bad, or inaccessible. --Timeshifter (talk) 19:44, 6 February 2024 (UTC)

Agreed with Redrose64. Graham87 (talk) 06:23, 7 February 2024 (UTC)

Graham87. Thanks. Is your screen reader able to decipher it at all?

I am wondering if anything on Help:Collapsing is accessible at all. If so, which examples? I would like to indicate that on that help page. I edit a lot table help pages, but I haven't done much on that page. --Timeshifter (talk) 12:13, 7 February 2024 (UTC)

Yes, it's decipherable, but much clunkier with the pseudocaption. this edit made before your comment here has fixed things accessibility-wise as far as I'm concerned ... thanks for that Redrose64. I'm not an HTML expert by any means (just a screen reader user) and this line of questioning (as well as your general approach on this page) is getting rather tedious. Graham87 (talk) 14:42, 7 February 2024 (UTC)

Thanks for the info about the clunkiness. I apologize for any irritation I may have caused.

Are you saying that the other examples on that page are accessible? There are 4 other examples on that help page with pseudocaptions. I didn't add them.

Maybe some others with screen readers can take a look at that.

--Timeshifter (talk) 15:12, 7 February 2024 (UTC)

The ones without captions don't use pseudocaptions in the same sense. They're OK I guess to *me* ... but don't take that as an indication of anything. I don't think this conversation is worth taking any further. Graham87 (talk) 17:12, 7 February 2024 (UTC)

OK. I think I see what you and Redrose64 are talking about now. All of the examples on that page are single tables. And the top text that is showing is the same as if it were not a collapsible table. So they are not pseudo-anything.

The example I tried to add only had the top text of the wrapping table. Not of the nested table inside of it. And it is clunky and inaccessible.

In contrast to the nested tables used for the wikitext/results pairs. Those are an example of accessible nested tables according to this talk section higher up: #Are these nested tables accessible?

--Timeshifter (talk) 18:42, 7 February 2024 (UTC)

Template:Collapse top, and Template:Collapse bottom

{{collapse top}} and {{collapse bottom}}

I use this method on my user page. I know it is not for articles.

Is it accessible? I want to find out what is the most accessible method for collapsed boxes on user pages.

I put the same table inside it from the previous talk section. I changed the title a bit. When I narrow my browser window, the title wraps.

A longer title needs to wrap for cell phones, portrait view, etc.
Name Score John 59 Bob 72

--Timeshifter (talk) 12:07, 7 February 2024 (UTC)

Yes, it is. Graham87 (talk) 14:46, 7 February 2024 (UTC)

Thanks. --Timeshifter (talk) 15:13, 7 February 2024 (UTC)

The {{collapse top}}/{{collapse bottom}} templates use a div element as the fundamental construct. This is completely different from misusing a table to achieve a similar effect, i.e. collapsing the enclosed content. Per the HTML 5.2 spec, The <div> element has no special meaning at all. It represents its children. It can be used with the class, lang, and title attributes to mark up semantics common to a group of consecutive elements. - in other words, a div element has no inherent semantic meaning; it is a convenient means for delimiting a block of page content. --Redrose64 🌹 (talk) 23:17, 7 February 2024 (UTC)

Thanks. I wish the collapsed box aligned to the left. I don't see a parameter for doing that. Unless I am missing something. I did find a width parameter. And a text alignment parameter.

Unfortunately, the width parameter is not a max-width. It does not wrap.

I did find a weird indent= parameter. By using negative percents or em units one can move the box to the left. But if set wrong the box extends off the screen to the left. So it is an accessible collapsible box that needs work. I may take this up on that template's talk page. I need to look at this on other monitors to see if it is aligned approximately the same. On my main monitor it currently lines up even with the text on the talk page. But when I increase my text size via the browser zoom setting the alignment changes. As does lessening the browser window size. Both push the box off the page to the left.

A longer title needs to wrap for mobile portrait view, etc.. More text to test wrapping.
Name Score John 59 Bob 72

--Timeshifter (talk) 12:43, 8 February 2024 (UTC)

" I wish the collapsed box aligned to the left" you mean instead of being fullwidth, you want it to be as wide as the title and left align ? —TheDJ (talk • contribs) 13:10, 8 February 2024 (UTC)

Yes, exactly. And I want the title to wrap as it does now when no width parameter is added.

I am on a bigger monitor now, and the box is a few inches away from the left side. Whereas on the smaller monitor I had the box lined up with the left side of the text. Using the indent= parameter.--Timeshifter (talk) 14:27, 8 February 2024 (UTC)

Template:CTableStart and Template:CTableEnd

Template:CTableStart and Template:CTableEnd

This template is also only for user pages. The heading wraps in default mode. It has a "table-width" parameter that can use em units, percents, etc.. The heading width set by em units will not wrap.

The heading width set by a percent will wrap in narrower screens and browser widths. Still need a template with a width that exactly matches header text width, and wraps. Percent widths will not look the same in different tablet and desktop screen resolutions. In some the heading will be on one line, and in others it will be on 2 lines. A "max-width" setting is needed. But this template is better than the previous one for setting header width. If it is accessible.

A longer title needs to wrap for mobile portrait view, etc.. More text to test wrapping.
Name Score John 59 Bob 72

{{CTableStart|heading=A longer title needs to wrap for mobile portrait view, etc.. More text to test wrapping.|table-width=70%}}
{|class=wikitable
! Name !! Score
|-
| John || 59
|-
| Bob || 72
|}
{{CTableEnd}}

--Timeshifter (talk) 11:43, 29 February 2024 (UTC)

Notice of MOS talk page discussion re MOS:COLOR

This discussion is related to MOS:COLOR, specifically to the bit that says do not use colored text or background unless its status is also indicated using another method, such as an accessible symbol matched to a legend, or footnote labels. Comments are welcome over there. – Jonesey95 (talk) 01:46, 9 February 2024 (UTC)

How to correctly mark up content displayed vertically

Of course, line breaks should not be used for purposes other than breaking up text semantically. The ubiquitous enlightened move is the use of HTML lists with no styling per templates like {{unbulleted list}}. However, this does not always seem like the best solution either, when it's harder to see components as items in a list, like within this table I've written. Is there a solid method to simply display blocks of content vertically without this carrying semantic information that harms accessibility and general correctness? Remsense诉 00:10, 26 February 2024 (UTC)

Not really. Remember that people also often list things in a sentence like: I went to the grocery store to buy bread, milk, tuna and pasta. We don't go around marking that up as an unbulleted list either. Text has semantics as well. It's when we start removing the text, the commas, the 'or' and 'and's where things start to become a problem and artificial solutions need to be sought. —TheDJ (talk • contribs) 12:30, 3 March 2024 (UTC)

The example I'm thinking of is when people put line breaks to make words fit better into the header of a table column. Usually, the solution is to fix the width of the column, but this doesn't always work. Remsense诉 12:34, 3 March 2024 (UTC)

Isn't that precisely a proper use of <br>s? Nardog (talk) 12:45, 3 March 2024 (UTC)

No. Line breaks are semantically equivalent to a paragraph break, what is generally referred to as phrasing content in the HTML standard, as opposed to flow content.[3] It is indicating a "pause" or "break": pause for two seconds in your head if you encounter one while reading. From MDN:[4]

The <br> HTML element produces a line break in text (carriage-return). It is useful for writing a poem or an address, where the division of lines is significant.

The <br> element has a single, well-defined purpose — to create a line break in a block of text. As such, it has no dimensions or visual output of its own, and there is very little you can do to style it.

Creating separate paragraphs of text using <br> is not only bad practice, it is problematic for people who navigate with the aid of screen reading technology. Screen readers may announce the presence of the element, but not any content contained within <br>s. This can be a confusing and frustrating experience for the person using the screen reader.

Use <p> elements, and use CSS properties like margin to control their spacing.

Remsense诉 13:06, 3 March 2024 (UTC)

So how would a usage like the one used in the infobox of Chapter Fifty-Eight: In Memoriam |title=Chapter Fifty-Eight: <br />In Memoriam be semantically correct? Gonnym (talk) 14:13, 3 March 2024 (UTC)

I think in this case, there's at least two separate clauses separated with a colon. It's worst when it's done for only typesetting reasons. Remsense诉 14:16, 3 March 2024 (UTC)

Guidelines around bulleted lists of non-sentences

Hi all, I was recently informed by Isaidnoway that a list article I wrote years ago, List of Mystery Dungeon video games, has some accessibility problems. Specifically, that the lack of periods at the end of each line in the "notes" sections resulted in screen readers reading the whole thing out as a run-on sentence. There doesn't seem to be any guidance on this in these guidelines that I could find; the examples in the list section all have periods as they are complete sentences, but the Bulleted vertical lists section uses two-word fragments and doesn't use periods. The only screen-reader software I have access to is Mac Voicover, which interjects a "bullet" at the start of each line, so I don't know what other software does. Essentially I'm asking two things: 1 is not having periods at the end of sentence fragments in a bulleted list an issue? And 2, if it is, can it be explicitly stated in the guidelines? As a delegate for Featured List Candidates I try to enforce ACCESS guidelines for lists, but I can't enforce something that's not explicitly written. --PresN 22:38, 2 March 2024 (UTC)

Pinging Graham87 for his input. How does your software read the Notes sections in List of Mystery Dungeon video games? Does it pause at the end of each sentence in the Notes section to indicate a paragraph break? Isaidnoway (talk) 00:54, 3 March 2024 (UTC)

@PresN and Isaidnoway: Both the windows screen readers I have access to, JAWS and NVDA, put list items like this on their own line ... and JAWS also adds a bullet; they both make it clear that each item is separate under normal conditions. The lack of punctuation might be a problem for some people but honestly it's a normal English formatting convention so if it's an issue, those people will have to get used to it. Screen readers mispronounce and misread things relatively often (even the word "misread" has two pronunciations ... like "misreed" or "misred") and proficient screen reader users get used to the idiosyncrasies of the system(s) they use. Graham87 (talk) 08:00, 3 March 2024 (UTC)

What Graham said. And I'd like to repeat a common point, that some people see all of this as some sort of black and white rulebook that has to be followed, which it is not. The guidelines have to be followed within reason, because that often will improve the situation, but they are not a directorate towards perfect accessibility, as such a thing doesn't exist. Correct mistakes where they apply, improve where possible, but don't take a weedwhacker at everything as a lot of nuance applies. Yes, having periods/punctuation at the end of sentences is probably better in many situations (especially when there is nothing like a list to distinguish the items instead), but that is not the same as "not having periods is forbidden" and it should not be something that should come up in a featured article review in my opinion. A lot of these kinds of things are intentionally not a rule, because it should not be arbitrarily enforced, it changes way too often to document or is pretty common outside the Wikipedia bubble of perfection. —TheDJ (talk • contribs) 12:23, 3 March 2024 (UTC)

Thank you all for answering! --PresN 04:41, 7 March 2024 (UTC)

Text in images

One thing I can't see covered by the MOS is the matter of text size in images. There has been a trend in recent years for more and more information to be added into maps used in election article infoboxes, such as bar charts, pie charts, legends etc (for example, there is currently a proposal to change the US presidential election map from this (in which the text is legible at the scale it is shown in the infobox) with this (which has text that is completely illegible at the scale shown in the infobox, and some so small it is not even legible when clicking through to the file page and can only be read by opening the image full screen).

Is this an accessibility issue, and if so, should there be a minimum font size requirement for text in images (e.g. that the image is shown at a size where the text appears equivalent to a certain font size)? Cheers, Number 57 12:56, 20 March 2024 (UTC)

Requesting an accessibility "spot check"

I've been working on Chinese characters and related articles for a while, and one of my constant concerns is ensuring equal accessibility. Specifically, I've done a lot of work ensuring screen readers will function properly concerning the large amount of both tabular information and non-English information, but any insights or comments whatsoever would be appreciated.

—Hey, shouldn't there be an Accessibility noticeboard? Or is that this page? Remsense诉 18:03, 31 March 2024 (UTC)

It's this page. I can't think of anything more that can be done accessibility-wise (making non-Latin text accessible can be hard!), but thanks for your efforts. Graham87 (talk) 06:28, 1 April 2024 (UTC)

Thank you very much for your expertise as always, Graham. Remsense诉 11:10, 1 April 2024 (UTC)

Relevant requested edits

Some of you may remember that I've made it a point to add alt text and table semantics to articles for several years. Some of you may also know that I am under WP:0RR for edit-warring so I cannot engage in any reverting or otherwise undoing others' edits. I have had a recent article and template where I have added proper table semantics and someone else removed them and that someone is unwilling to re-add them. If anyone is motivated, see Template talk:2024 UFL standings and Talk:Michigan Panthers (2022). ―Justin (koavf)❤T☮C☺M☯ 23:09, 16 April 2024 (UTC)