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: | ||||||||||||||||||||||||||||||||||
|
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 5 7 12:56, 20 March 2024 (UTC)
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)
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)
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 |
-- Qwerty284651 ( talk) 15:04, 29 May 2024 (UTC)
Do 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)
.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)
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)
The 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)
Graham87. 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)
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: | ||||||||||||||||||||||||||||||||||
|
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 5 7 12:56, 20 March 2024 (UTC)
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)
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)
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 |
-- Qwerty284651 ( talk) 15:04, 29 May 2024 (UTC)
Do 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)
.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)
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)
The 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)
Graham87. 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)