Wikipedia talk:Manual of Style/Accessibility
Please place new discussions at the bottom of the talk page. |
This is the talk page for discussing improvements to the Manual of Style/Accessibility page. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16Auto-archiving period: 90 days |
This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||
|
Text in images
editOne 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)
- Number 57. People need to look at the image at the scale it is shown in the infobox in cell phones too. For example, see this:
- Wikipedia talk:WikiProject Maps#Ability to distinguish "D" on map on cell phones
- See table: Over 50 percent of website traffic is from cell phones.
- --Timeshifter (talk) 04:37, 7 June 2024 (UTC)
- I agree, but is there actually a guideline/policy on this, or a desire for one? Number 57 03:02, 8 June 2024 (UTC)
- Number 57. I think we are at the stage of drumming up support. I tried to make the text size as large as possible in the maps in this category:
- c:Category:English-language SVG choropleth maps of the United States made with templates
- The text could be made larger if 2-letter state abbreviations were used instead of full state names. But most people do not know what all the abbreviations stand for.
- As I just noted at the previously-linked talk page:
- Wikimedia is rolling out a text sizing menu with 3 choices: small, standard, and large. I have it set on large. So there is a definite desire for more accessibility. Map editors should honor this too. See:
- https://eu.wikipedia.org/wiki/Topic:Y5nbfld32in1ud0k
- It is a default setting for logged out users. Log out and bypass your cache to see the text-sizing menu. It can be hidden to a link toggle that shows the menu.
- Logged in users can enable it via the beta preferences:
- Special:Preferences#mw-prefsection-betafeatures - "Accessibility for Reading (Vector 2022)".
- So people are waking up to the need to make Wikipedia even more accessible.
- --Timeshifter (talk) 12:23, 14 June 2024 (UTC)
- I agree, but is there actually a guideline/policy on this, or a desire for one? Number 57 03:02, 8 June 2024 (UTC)
Requesting input
editDoes 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 |
-- Qwerty284651 (talk) 15:04, 29 May 2024 (UTC)
- Qwerty284651. You might have a look at the tools here:
- c:Commons:Map resources#Accessibility and map colors
- Take a screenshot of the table in question and upload it to the color blindness checkers.
- Also, copy the color numbers of a background and text, and run them through the contrast checkers.
- The hex code for black text is #000000. See also:
- Wikipedia:Manual of Style/Accessibility/Colors
- Wikipedia:Colour contrast
- Help:Link color
- --Timeshifter (talk) 04:25, 7 June 2024 (UTC)
Is Template:static row numbers accessible?
editDo screen readers detect static row numbers as a row header or do they jump straight into the data cell in column 2? I am asking whether it is accessible. Does it require an "id=...". Otherwise, I can just use regular data cells. Qwerty284651 (talk) 16:34, 5 June 2024 (UTC)
- They jump straight into the data cell in column 2. (but they do read the static row numbers when not in table navigation mode). I have no idea how you'd make them properly accessible. Graham87 (talk) 17:25, 5 June 2024 (UTC)
- It looks to me like the first column is not a real table column but extra CSS-generated content that is inserted before the first real column and styled to appear like a table cell. The CSS is in Template:Static row numbers/styles.css, and this contains several CSS rules, of which five actually produce the row numbers (the others are concerned purely with visual appearance: alignment, backgrounds, borders, colour, font and padding). These five are: W3C documentation for these properties is as follows:
.static-row-numbers { counter-reset: rowNumber; } .static-row-numbers tr::before { content: ""; display: table-cell; } .static-row-numbers thead + tbody tr:first-child:not(.static-row-header):not(.static-row-numbers-norank)::before, .static-row-numbers tbody tr:not(:first-child):not(.static-row-header):not(.static-row-numbers-norank)::before { counter-increment: rowNumber; content: counter(rowNumber); } .static-row-header-text.static-row-numbers thead tr:first-child::before, .static-row-header-text.static-row-numbers caption + tbody tr:first-child::before, .static-row-header-text.static-row-numbers tbody:first-child tr:first-child::before { content: "No."; } .static-row-header-hash.static-row-numbers thead tr:first-child::before, .static-row-header-hash.static-row-numbers caption + tbody tr:first-child::before, .static-row-header-hash.static-row-numbers tbody:first-child tr:first-child::before { content: "#"; }
counter-reset
,content
,display
,counter-increment
and also the::before
pseudo-element. --Redrose64 🌹 (talk) 19:54, 5 June 2024 (UTC)- Pinging @Jts1882, Timeshifter, Guarapiranga, and Jroberson108:, the editors involved in its development, to look more into it and make it more accessible. Qwerty284651 (talk) 20:18, 5 June 2024 (UTC)
The only thing I can think to change that might make it more accessible is adding content before the first td/th in the row (tr :first-child::before) instead of before the row (tr::before). This way it's in the row instead of before it.Jroberson108 (talk) 21:18, 5 June 2024 (UTC)- I misspoke. The current styles place the content inside the table rows. Doing what I suggested would prepend the content inside the first td of each row. Jroberson108 (talk) 00:52, 6 June 2024 (UTC)
- Pinging @Jts1882, Timeshifter, Guarapiranga, and Jroberson108:, the editors involved in its development, to look more into it and make it more accessible. Qwerty284651 (talk) 20:18, 5 June 2024 (UTC)
- It looks to me like the first column is not a real table column but extra CSS-generated content that is inserted before the first real column and styled to appear like a table cell. The CSS is in Template:Static row numbers/styles.css, and this contains several CSS rules, of which five actually produce the row numbers (the others are concerned purely with visual appearance: alignment, backgrounds, borders, colour, font and padding). These five are:
Graham87 and others with screen readers. The following table has the hash symbol (#) as the row number column header. How does your screen reader see it? This example is adapted from Template:Static row numbers#Display hash ("#") symbol in column label.
Color | Data | ||
---|---|---|---|
A | B | C | |
Red | 1 | 2 | 3 |
Lime | 4 | 5 | 6 |
Gold | 7 | 8 | 9 |
Wikitext:
{{static row numbers}}
{| class="wikitable static-row-numbers static-row-header-hash"
|+ Example table with hash as row number column header
|-
! rowspan=2 | Color
! colspan=3 | Data
|- class=static-row-header
! A !! B !! C
|-
...
--Timeshifter (talk) 04:26, 7 June 2024 (UTC)
- @Timeshifter: It doesn't see the row numbers as part of the table ... because they still aren't, technically, as you can see from the table's HTML source. As I implied above there is probably no way to fix this. Graham87 (talk) 07:46, 7 June 2024 (UTC)
- I tried with ChatGPT and after they tried JavaScript and PHP they finally gave up when I asked for a pure html and CSS solution. Gonnym (talk) 08:02, 7 June 2024 (UTC)
- It seem like the CSS counter is not critical content since the template is optional and the tables are understandable without it. Basically a nice to have. Would that mean it is decorative content that can be ignored regarding accessibility? Jroberson108 (talk) 12:49, 7 June 2024 (UTC)
- Graham87. So I guess we can ignore adding the hash as a column header, as far as you are concerned? In other words, there is no benefit to you? Very few people add any type of column header to the static row numbers. Sighted readers don't need it at all.
- But if the hash is of any benefit to you, in some mode or other of the screen reader, then it is easy to make it be placed as the column header by default. No choice to remove it. That would be my preference if it is of benefit to screen-reader users in any way. --Timeshifter (talk) 02:46, 8 June 2024 (UTC)
- @Timeshifter: Nope, it does nothing for screen reader users. Graham87 (talk) 05:24, 8 June 2024 (UTC)
- It seem like the CSS counter is not critical content since the template is optional and the tables are understandable without it. Basically a nice to have. Would that mean it is decorative content that can be ignored regarding accessibility? Jroberson108 (talk) 12:49, 7 June 2024 (UTC)
- I tried with ChatGPT and after they tried JavaScript and PHP they finally gave up when I asked for a pure html and CSS solution. Gonnym (talk) 08:02, 7 June 2024 (UTC)
Diff color change on mobile web editor
editThe mobile web editor used to show added and removed text in red and green respectively, making it clear to 97% of editors what is happening in that diff. These colors have now been changed to blue and yellow, so that no one can tell which text was added vs removed. This change will lead to good edits getting mistakenly reverted and contributors driven away from editing
I'm pretty sure this is a misguided accessibility change but I don't know who is in charge of this feature. (t · c) buidhe 18:58, 21 June 2024 (UTC)
- @Buidhe Hi, this change for the mobile web editor was made in February (in phab:T350181). I believe the best place for feedback would be mw:Talk:Reading/Web/Accessibility for reading, where the relevant team will see it. I hope that helps. Quiddity (WMF) (talk) 21:08, 21 June 2024 (UTC)
Accessibility of scrolling tables. Different template
editGraham87. You noted in this discussion, Talk:COVID-19 pandemic deaths/Archive 1#Scrolling versus expanded tables, that the scrolling tables in the related article (COVID-19 pandemic deaths) were not a problem. You said: "it doesn't affect totally blind screen reader users." Those were a particular set of scrolling tables discussed here:
I want to know if this is also true for the scrolling tables (from a different template) in this version of a list article with 3 scrolling tables:
This method for scrolling tables is discussed here:
--Timeshifter (talk) 14:22, 6 July 2024 (UTC)
- @Timeshifter: They generally work fine here. The only exception is JAWS under Chrome, but I think that's a JAWS issue and not a problem with the tables per se ... the combination of JAWS and Chrome is having problems with all sorts of tables at the moment. Graham87 (talk) 14:32, 6 July 2024 (UTC)
- All sticky headings use pure CSS. For screenreader users it should be just fine because of that. If anything, it's more likely to be a problem for people with partial blindness or for older users etc, as the position of the element changes, which might be confusing to some. I can also imagine that the max-height vertical scroller can be a bit of a problem for screenreader users on mobile phones, as having a vertical scroller within a vertical scroller can be confusing for discovery, but as long as there are no controls inside the vertical scroller, that too seems unlikely to cause a problem. —TheDJ (talk • contribs) 08:15, 8 July 2024 (UTC)
Collapsing on mobile
edit- Note that mobile versions of the website do not support collapsing, so any collapsible content will automatically be uncollapsed.
This seems out of date; it works just fine on my phone or when I try the mobile preview on my computer. I'll remove it for now but let me know if anyone objects. Closed Limelike Curves (talk) 19:13, 27 July 2024 (UTC)
Alt text for images
editDear visually impaired readers of Wikipedia. I sometimes add alt text to images to aid accessibility. I aim to be as succinct as possible while also being as correct as possible. The latter goal tends to make the descriptions lengthier but I try to keep them under 250 words. I mention color because I think that's important even if some some of our visually impaired readers have been blind since birth. I am not visually impaired and I don't use screen readers. The reason I am writing is to ask for suggestions of things to avoid when writing alt text. Things that bother you in alt text that you wish the writers would not do. That way I could better understand things from the perspective of a person who uses alt text. By the way, I've also started to use AI image generators to see how well my descriptions can duplicate the image. It's an interesting experiment and the results suggest that a picture requires far far more than a thousands words to describe as is commonly said. Nevertheless, most of the time the descriptions are reasonable approximations. Jason Quinn (talk) 10:21, 13 August 2024 (UTC)
- @Jason Quinn: Thanks very much for this. As a totally blind person from birth, I can't think of anything to add but I find it hard to evaluate alt text because I don't know what I'm missing; see my comments in this discussion. Graham87 (talk) 15:30, 13 August 2024 (UTC)