Wikipedia talk:Manual of Style/Accessibility

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

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.[1] It is indicating a "pause" or "break": pause for two seconds in your head if you encounter one while reading. From MDN:[2]

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)

Requesting input

Does the following chart pass WCAG? Qwerty284651 (talk) 15:04, 29 May 2024 (UTC)

Wikipedia talk:WikiProject Tennis#Performance timeline

Tournament		2019	2020	2021	2022	2023	2024	W–L	Win %
Grand Slam events	Australian Open	2R	4R	4R	SF	4R	3R	17–6	74%
	French Open	4R	W	QF	W	W		28–2	93%
	Wimbledon	1R	NH	4R	3R	QF		9–4	69%
	US Open	2R	3R	4R	W	4R		16–4	80%
	Win–loss	5–4	12–2	13–4	21–2	17–3	2–1	70–16	81%
YEC	WTA Finals	DNQ	NH	RR	SF	W		9–3	75%
Team events	Summer Olympics	NH		2R	NH			1–1	50%
	Billie Jean King Cup	A	A		Q	A		2–0	100%
WTA 1000 events	Dubai Championships	A	N1K	3R	N1K	F		4–2	67%
	Qatar Open	N1K	2R	N1K	W	N1K		6–1	86%
	Indian Wells Open	Q2	NH	4R	W	SF		12–2	86%
	Miami Open	Q2	NH	3R	W	A		7–1	88%
	Madrid Open	A	NH	3R	A	F		7–2	78%
	Italian Open	A	1R	W	W	QF		14–2	88%
	Canadian Open	3R	NH	A	3R	SF		6–3	67%
	Cincinnati Open	2R	1R	2R	3R	SF		5–5	50%
	China Open	A	NH			W		6–0	100%
	Wuhan Open	A	NH					0–0	–
	Win–loss	3–2	1–3	12–5	24–2	27–6	0–0	67–18	79%
Career statistics		2019	2020	2021	2022	2023	2024	W–L	Win %
Tournaments		11	6	16	17	18	2	Career: 70
Titles		0	1	2	8	6	0	Career: 17
Finals		1	1	2	9	8	0	Career: 21
Hard win–loss		7–7	7–4	20–11	47–7	42–8	7–1	130–38	77%
Clay win–loss		7–3	7–1	12–2	18–1	19–2	0–0	63–9	88%
Grass win–loss		0–2	–	4–2	2–1	7–1	0–0	13–6	68%
Overall win–loss		14–12	14–5	36–15	67–9	68–11	7–1	206–53	80%
Win (%)		54%	74%	71%	88%	86%	88%	Career: 80%
Year-end ranking		61	17	9	1	1		$24,592,763