![]() | This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Feedback requested at Wikipedia_talk:Manual_of_Style#Typographical_symbols_used_for_notes_and_accessibility. Thanks. ― Justin (koavf)❤ T☮ C☺ M☯ 02:03, 21 March 2020 (UTC)
Need help with advanced coding so we don't deter potential new editors because they can't see pages properly. Pls see Wikipedia talk:WikiProject Accessibility#Another module tutorial with accessibility problems.-- Moxy 🍁 16:03, 7 April 2020 (UTC)
Our document says We aim to adhere to Web Content Accessibility Guidelines 2.0
Should we be developing to 2.0 or 2.1 of Web Content Accessibility Guidelines? 2.1 came out in June 2018 ( new in 2.1). I took a quick glance in the archives and didn't see anything about this, apologies if I missed the discussion. Kees08 (Talk) 15:59, 7 April 2020 (UTC)
Should tables always include a caption? -- RexxS ( talk) 21:41, 6 April 2020 (UTC)
In most popular screen readers, it is possible to bring up a (voiced) list of all of the table captions on a page. That then allows the screen reader user to navigate directly to the table that they want to read.
As Graham87 has explained, if a table has no caption, then JAWS will voice the first column heading to 'identify' the table. We really should not be letting that happen, so there is an implicit expectation that a table will have a caption.
Graham also tells me that it's common for a screen reader user to navigate by calling up a list of headings and use that to navigate to the section that they want. That has lead us to accept tables without captions where the table comes immediately below a heading and the caption would simply duplicate that heading. That's a concession to sighted editors who don't like the look of repeated text – simply an aesthetic consideration. Nevertheless that still leaves screen reader users who navigate via tables with the issue of hearing the first column title instead of a sensible caption, so it's less than ideal.
I am requesting comments from editors with the intention to include a phrase along the lines of "Tables should always include a caption" in the guidance at Wikipedia:Manual of Style/Accessibility #Data tables if the RfC results in support for that. To be clear: this would mean that captions should be included in data tables, even when the table immediately follows a heading which would duplicate the caption. -- RexxS ( talk) 21:41, 6 April 2020 (UTC)
I've placed at notice at WP:CENT and at Wikipedia talk:WikiProject Accessibility. -- RexxS ( talk) 21:56, 6 April 2020 (UTC)
Please confine threaded discussion to the discussion section.
>>
BEANS X2
t
10:54, 20 April 2020 (UTC)As I said above, I reluctantly oppose this RFC as worded too broadly. Template:Navbox, for example, uses table markup, but unless I am mistaken (which happens regularly), it provides neither a caption nor a summary. How would our navboxes be modified to have a caption? If this is a straw man, feel free to set it on fire; I'm just looking at what comes out of Special:ExpandTemplates when I put Template:AKB48 or pretty much any other navbox in it. – Jonesey95 ( talk) 23:51, 6 April 2020 (UTC)
so I really don't think this RfC can possibly have any bearing on the use of tables for layout. -- RexxS ( talk) 00:07, 7 April 2020 (UTC)When using a table to position non-tabular content, help screen readers identify it as a layout table, not a data table. Set a
role="presentation"
attribute on the table, and do not set anysummary
attribute. Do not use any<caption>
or<th>
elements inside the table, or inside any nested tables.
"I am requesting comments from editors with the intention to include a phrase along the lines of "Tables should always include a caption" in the guidance at Wikipedia:Manual of Style/Accessibility #Data tables"and I don't think that could be any clearer. I won't try to persuade you to change your opposition, as it should be sufficient for the closer of the RfC to determine the community's consensus on what wording would be appropriate and the context to which it applies. -- RexxS ( talk) 00:33, 7 April 2020 (UTC)
@ NinjaRobotPirate: Hi, I was wondering if there were any specific exceptions that apply that you were thinking of. I am sure there could be exceptions, but I was hoping we could clear up if a similarly worded section header directly above the table could be considered an exception. Did you mean that case, or other exceptions we may not be thinking of? I suppose the proposal is clear, as it says To be clear: this would mean that captions should be included in tables, even when the table immediately follows a heading which would duplicate the caption, but I wanted to make sure you saw that. Thanks! Kees08 (Talk) 15:42, 7 April 2020 (UTC)
Outside of Wikipedia, I assume that formal papers generally expect tables to have a caption. My guess is in WP that
Now that people are realizing the accessibility issues, some might be reticent to reword (or remove) those legacy headers that would sound repetive by adding the table captions (that ideally would have been used to begin with). Preferably, we would address accessibility while minimizing the effort to retrofit headers. For example, Eagles247 and Koavf found a way for {{ NFL roster}} at User_talk:Koavf/Archive055#Template:NFL_roster to retrofit an existing template to move existing display text to the caption with no visual difference for sighted readers. This is not always possible, depending on the template.— Bagumba ( talk) 17:29, 9 April 2020 (UTC)
The oppose from Jweiss11 typifies the flawed argument "We've been ignoring the needs of the visually impaired for years, so we should be free to carry on doing it." There's no recognition that aesthetic issues such as a caption repeating a header are very minor compared to the need for screen reader users to have a sensible way of navigating to a particular table. Consider 1901 Michigan Wolverines football team#Schedule where editors leave screen reader users to identify that table as "Date". There's absolutely no reason why Module:CFB schedule should not add a caption tag at line 360. Consider Fielding H. Yost#Head coaching record where screen reader users need to navigate to the table called "Year". How unhelpful is that? What does it really matter if we take the trouble to put "Head coaching record" as the heading and the table caption? Would the table even need its own section if the table had a proper caption? -- RexxS ( talk) 22:56, 9 April 2020 (UTC)
"Has anyone explained why we can't have a field just for the screenreaders to solve this problem without creating redundant text in the standard displays?"There are no fields. The caption text is not redundant, and there are no standard displays. For the blind, there are no displays at all. If you read the discussion, you'll find that I already created a template Template:Sronly that seems to be able to instruct modern browsers not to display a piece of text, while allowing screen readers to voice that text.
The RfC will expire within 48 hours, and is probably ripe for closure anyway. I suggest that we ask an uninvolved administrator or experienced user to close this RfC as the question poses a significant change to prior practice.
Should the RfC result in support for the question, I would like the closer to confirm a form of words for the guideline that best represent the consensus expressed in the debate. My suggestion would be adding the following sentence to the end of the Caption section in Wikipedia:Manual of Style/Accessibility #Data tables:
I suggest that anyone should feel free to suggest alternative wording, but please don't re-legislate the entire discussion. We should be trying to help the closer, not convince them of our own view. Cheers -- RexxS ( talk) 22:40, 4 May 2020 (UTC)
A quick follow-on related to this: I noticed that the default "insert table" button in the wikitext editor does not include a caption element by default, and have filed phab:T252350 so that new tables added this way are encouraged to include a caption. The VisualEditor insert table option does already include space for a caption. the wub "?!" 21:54, 10 May 2020 (UTC)
This addition does not seem useful to me. It moves from accessibility advice into style advice, and small tags are useful for reasons other than semantic purposes, like shrinking the second line of an infobox title (larger by default) so that it shows as normal-sized text. I'm sure there are other examples. – Jonesey95 ( talk) 22:48, 16 April 2020 (UTC)
At Wikipedia:Manual of Style/Accessibility#Text there is guidance on transliterations:
Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
It's not clear how to do this. It would be very helpful if there were examples. For instance, should the transliteration appear following the non-Latin text and appear in parentheses? Coastside ( talk) 19:43, 13 May 2020 (UTC)
Do things like UEFA Euro 2020#Venues cause problems? First, they're fixed size. Second it's a type of gallery. Third, they're in oddly formatted tables. Fourth, no alt text. Walter Görlitz ( talk) 18:27, 18 May 2020 (UTC)
![]() |
---|
Wembley Stadium |
Capacity: 90,000 |
![]() |
![]() |
---|
Allianz Arena |
Capacity: 75,000 |
![]() |
![]() |
---|
Stadio Olimpico |
Capacity: 72,698 |
![]() |
![]() |
---|
Olympic Stadium |
Capacity: 68,700 |
![]() |
![]() |
---|
Krestovsky Stadium |
Capacity: 68,134 |
![]() |
![]() |
---|
Puskás Aréna |
Capacity: 67,215 |
![]() |
![]() |
---|
Arena Națională |
Capacity: 55,600 |
![]() |
![]() |
---|
Johan Cruyff Arena |
Capacity: 54,990 |
![]() |
![]() |
---|
Hampden Park |
Capacity: 52,063 |
![]() |
![]() |
---|
Aviva Stadium |
Capacity: 51,700 |
|
![]() |
---|
Parken Stadium |
Capacity: 38,065 |
|
There is an rfc on the layout of tables listing adult entertainment awards, and I recognised an accessibility issue with the reading order of the table headers for a screen reader. Wikipedia_talk:WikiProject_Pornography#rfc_49102E2 I referred to WP:ACCESSIBILITY, but then realised there is no advisory on headers and reading order in the section about data tables for people to refer to. Morbidthoughts ( talk) 07:51, 20 May 2020 (UTC)
I'm not sure where I read it, but I read that there were issues with some screen readers and tables that used rowspans. Has this been resolved or are we even seeking resolution? They are heavily used in articles about musicians and sportspeople. I'm curious if we should be approaching those projects or if a larger consensus needs to be reached. Walter Görlitz ( talk) 06:30, 12 May 2020 (UTC)
{{
shade|75%}}
being obvious culprits. --
RexxS (
talk)
19:58, 12 May 2020 (UTC)
Per MOS:TABLECAPTION, all data tables should have captions leading them. Sometimes, the captions are pretty bare-bones, such as "Records by season" or "Albums", whereas I am of the opinion that they should be descriptive enough to stand on their own--i.e. "[Sports team] records by season" or "[Recording artist] albums". My thinking here is two-fold: 1.) the function of a caption is to describe the contents of the table, so unless a table is about the concept of records by season or generally about albums, it's necessary to add these caveats and 2.) sometimes, these tables are inserted into other articles--e.g. with many lists of television series episodes--so there are times when the context is not quite as obvious as when the table is included in [sports team]'s or [recording artist]'s bios. Thoughts on best practices here and any language we can use at MOS:TABLECAPTION to make the best practices clear? ― Justin (koavf)❤ T☮ C☺ M☯ 04:33, 27 May 2020 (UTC)
Is there any guidance on forcing linebreaks within infobox parameters that are not lists? See for example |office6=
on
Nancy Pelosi, but there are many more - seems to be particularly common in uses of {{
infobox officeholder}}. If this is something to be avoided I suggest it would be worthwhile to explicitly say so in this guideline.
Nikkimaria (
talk)
21:27, 29 May 2020 (UTC)
Is this discouraged under MOS:LISTGAP? That is, does it cause the problems for screen readers described there?
: I like this idea. [[User:Example]] * I don't like this idea. [[User:Example 2]] : I don't like this discussion. [[User:Example 3]]
― Mandruss ☎ 15:36, 19 May 2020 (UTC)
: I like this idea. [[User:Example]]
: I don't like this idea. [[User:Example 2]]
: I don't like this discussion. [[User:Example 3]]
* I like this idea. [[User:Example]]
* I don't like this idea. [[User:Example 2]]
* I don't like this discussion. [[User:Example 3]]
: I like this idea. [[User:Example]]
:* I don't like this idea. [[User:Example 2]]
: I don't like this discussion. [[User:Example 3]]
"Likewise, do not switch between initial list marker types (colons, asterisks or hash signs) in one list". It is principally about screen readers and I wrote an essay on it at WP:Colons and asterisks. -- RexxS ( talk) 18:25, 19 May 2020 (UTC)
I'm starting this discussion. [[User:Example]]
* I don't like this discussion. [[User:Example 3]]
"For example, in a discussion, do this best practice:"which seems to me to refer to discussions, as does
"When indenting in reply ...". Nevertheless if you can improve the wording, why not do it? I'd be interested to see what your additional example is. -- RexxS ( talk) 18:55, 19 May 2020 (UTC)
@ RexxS: The following could be the last example at LISTGAP:
nor this (use asterisk in an unbulleted thread):
I have an idea. [[User:Example]] * What is it? [[User:Example 2]]
― Mandruss ☎ 19:03, 19 May 2020 (UTC)
*
though. --
RexxS (
talk)
19:11, 19 May 2020 (UTC)
*
. The first poster that uses an indent creates a list and that's what needs to be preserved. Period. --
RexxS (
talk)
20:32, 19 May 2020 (UTC)
What if we could have discussions that aren’t lists?
I’m imagining something like:
I think the article could benefit from more images. [[User:Joe Bloggs.]] dtstamp {{ind1|p| No way! There are already too many scattered across multiple sections. [[User:N.A. Sayer.]] dtstamp }} {{ind2|p| {{re|N.A. Sayer}} We could move them to a gallery. [[User:Valerie G.]] dtstamp }}
Which could render as:
<p>I think the article could benefit from more images. <a href=...>User:Joe Bloggs.</a> dtstamp</p> <p class=mw-indent-1>No way! There are already too many scattered across multiple sections. <a href=...>User:N.A. Sayer.</a> dtstamp</p> <p class=mw-indent-2>@<a href=...>N.A. Sayer<a>: We could move them to a gallery. <a href=...>User:Valerie G.</a> dtstamp</p>
With CSS like:
.mw-indent-1 margin-left:2em; /* or 5vw, or whatever */ .mw-indent-2 margin-left:4em;
[I won’t go into the HTML5 idea of comments as sequences of (article(footer))(article(footer))... elements. And bulleted or numbered responses would still be lists, I guess.]
What would it mean for screenreaders and accessibility in general if our conversations were paragraphs (or similar) rather than lists?
— Pelagic ( messages ) Z – (22:51 Mon 01, AEST) 12:51, 1 June 2020 (UTC)
<dd><dd><dd><dd><dd>This is my 2¢</dd></dd></dd></dd></dd>
is an abomination, in so many ways.
Pelagic (
messages )
Z – (22:51 Mon 01, AEST)
12:51, 1 June 2020 (UTC)
i have been adding lang
template for person names, cities, college or journal titles on foreign wikis (es,de,pt etc.) am i doing right by adding template ?
Vishnuvardhan leela (
talk)
01:35, 15 June 2020 (UTC)
I have made a proposal for an accessibility feature for Wikipedia here - Wikipedia:Village pump (idea lab)/Archive 31#Colour text options - and I would love to hear the views of people involved in this project. Helper201 ( talk) 00:22, 24 June 2020 (UTC)
I was adding a caption to a table on a video game page, and realized that {{ Video game reviews}} (used on 10,000+ pages) didn't have a "caption" element; in looking at it, though, I'm not sure it's meeting ACCESS requirements besides that? Example at Final Fantasy XII#Reception. It has a "header row" that acts as a caption, and then three sub-tables that have a data row as a header, then a header row for column headers (no colscopes), then data rows for the data (no rowscopes). I can add col/rowscopes to the subtables, and convert the top-level header to a caption, but I'm not sure that it works for screen readers even with that. Can anyone confirm if it does/doesn't work as currently designed? -- Pres N 14:55, 29 June 2020 (UTC)
<figure>
<figcaption>Reception</figcaption>
<table><!-- one for each kind of data -->
<caption>Aggregator scores</caption>
<tr><th>Aggregator</th><th>Score</th></tr><!-- with scopes of course -->
<tr><td><!--maybe could be a th with row scope, though I tend toward td -->Agg1</td><td>Score1</td></tr>
<tr><td>AggN</td><td>ScoreN</td></tr>
</table>
<table><!-- ditto for reviews -->
<caption>Publication scores</caption>
...
</table>
<table><!-- ditto for awards -->
<caption>Awards</caption>
...
</table>
</figure>
A discussion is taking place to address the redirect
MOS:SMALL. The discussion will occur at
Wikipedia:Redirects for discussion/Log/2020 July 3#MOS:SMALL until a consensus is reached, and readers of this page are welcome to contribute to the discussion. –
Davey2010
Talk
18:03, 3 July 2020 (UTC)
User Koavf has decided to slow-burn-edit-war this, but I'm starting the discussion instead of following their very poor example.
It's unclear to me whether the editor seeks to allow "small" in infoboxes, etc, provided it's for "fine print". If so, they are effectively saying accessibility is unimportant for this "fine print", and I would strongly disagree. If not, the ambiguity needs to be cleared up. Either way, the sentence is so vague as to be fairly pointless; if somebody wants a piece of text smaller, they need only call it "fine print" to satisfy the guideline as written. Wikipedia content is not legal contracts. Finally, there's a WP:CREEP issue, and I don't know that hairs need to be split quite this finely. ― Mandruss ☎ 00:16, 30 June 2020 (UTC)
<small>...</small>
just to create a visual effect for any campaign of fixing the semantics to be successful. Most editors don't understand that the the 'small' tag carries a meaning for some users and re-users, and almost certainly don't care. --
RexxS (
talk)
12:49, 6 July 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm experiencing inappropriate pushback at Docklands Light Railway rolling stock. Two editors ( C2A06 and user:Thryduulf) are insisting that the combination of {{ DLR color}} (#00B2A9) with white text is "easier to read" than the template-chosen black. I've explained that the color contrast with white fails all four WCAG accessibility criteria, and provided a link to the color tool proving this: https://snook.ca/technical/colour_contrast/colour.html#fg=FFFFFF,bg=00B2A9 However, these editors continue to revert and ask for "discussion" . It's completely inappropriate to leave the article in a state which violates WP:COLOR. See discussion at Talk:Docklands_Light_Railway_rolling_stock#Infobox_color>— TAnthony Talk 03:10, 22 July 2020 (UTC)
Such as {{ Kintetsu Minami-Osaka Line}}. Should this be formally prohibited?-- GZWDer ( talk) 20:33, 10 August 2020 (UTC)
The s element represents contents that are no longer accurate or no longer relevant.This is a correct use of that element. -- Izno ( talk) 20:52, 10 August 2020 (UTC)
I know that over the years I've seen editors in the wild removing excessive rowspans from tables (See the language column) because of concerns that screen readers have trouble presenting the content, but I don't see anything in the guidelines that looks like an official stance on this. Am I missing something? Can the community clarify this in the MOS? Thanks, Cyphoidbomb ( talk) 16:25, 15 August 2020 (UTC)
People who understand table formatting may want to look at Wikipedia:Village pump (technical)#Expanding class=wikitable to make tables accessible to blind, and to align cell text. Whatamidoing (WMF) ( talk) 02:26, 20 August 2020 (UTC)
I have been watching as an editor has added game results to Portland Timbers–Vancouver Whitecaps rivalry and am worried about the accessibility of the tables that have resulted. I have not run it through a checker, but would like some advice, preferably on the article's talk page. Walter Görlitz ( talk) 23:37, 4 September 2020 (UTC)
Please see: Wikipedia talk:Manual of Style/Captions#Video timestamps. Involves how to specify times in A/V material: "4:31", "4 min 31 sec", "4 m. 31 s.", etc., etc. — SMcCandlish ☏ ¢ 😼 12:20, 26 October 2020 (UTC)
Please see:
— SMcCandlish ☏ ¢ 😼 05:35, 17 November 2020 (UTC)
On Template talk:Tick#Alt text we are discussing the most appropriate alt text for the check mark. Any comments would be welcome over there. — Martin ( MSGJ · talk) 20:08, 18 November 2020 (UTC)
Please see:
Wikipedia talk:WikiProject Disability/Style guide#Requested move 20 November 2020
—
SMcCandlish
☏
¢ 😼
20:51, 28 November 2020 (UTC)
Hi editors, I was directed to this page in my peer review. It is for a band, and it was brought up that the timeline for band members was not accessible as it relied only on colour to show information. I have added a letter code here to the timeline for better accessibility, but I was wondering if someone might have any further feedback about how to make the timeline better? Typically band timelines have just been published with just a colour code. Thanks in advance. SatDis ( talk) 08:10, 5 December 2020 (UTC)
Some of the advice about screen readers seems to be out of date and not literally correct. For example,
Do not use unpronounceable symbols such as ♥ (a heart symbol)
Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" cannot be reproduced into useful text by a screen reader and will usually be read as a question mark.
I just tried these in Apple’s VoiceOver (I am not a regular user). It reads them as “red heart suit,” “dagger” (while the recommended {{ †}} says “dagger image”), and “right arrow.”
I will adjust the corresponding text to say “often unpronounceable” and “might not.” — Michael Z. 16:37, 11 December 2020 (UTC)
{{†|alt=whatever you want}}
gives †, which says "whatever you want". Being able to specify what the dagger indicates is a considerable advantage over the symbol.It's not a good idea. I can't read the hearts symbol with JAWS." Now, it is true that screen readers have improved over the past ten years, but the most popular reader, JAWS, costs around $1,000 and many users may still be running older versions, so unless you're sure that the vast majority of screen readers used on Wikipedia can read those symbols (which I doubt you can claim), we ought to stick with unequivocal advice. -- RexxS ( talk) 17:45, 11 December 2020 (UTC)
"an image, an image of text or a pictorial or decorative character symbol (glyph) which imparts information nonverbally"(which is why I considered it was referring to non-ascii characters) and it recommends that
"an image with a text alternative can be used instead of the glyph."In my experience, the issue tends to be found in tables or lists where a compact marker is used either to represent a longer piece of text (♥ = "hearts suit"), or designate something († = "Captain").
Please see: Wikipedia:Templates for discussion/Log/2020 December 3#Template:Hover title and Template:Tooltip
Summary:
{{
Abbr}}
(a wrapper for <abbr>...</abbr>
) has long been abused for non-abbreviation markup (against the HTML specs).{{
Tooltip}}
, with <span>...</span>
for non-abbreviation use, but it was "merged" (not really) and redirected to {{Abbr}}
.{{
Hover title}}
was created to do the same thing, but with backwards parameters (and some additional features).{{Tooltip}}
then-redirect and {{
Hover title}}
template have been transcluded in tens of thousands of articles, mainly via infoboxes and other templates.{{
Tooltip}}
template, with all the features of {{Hover title}}
but preserving the {{
Abbr}}
parameter order (to not break deployed translcusions).{{
Hover title}}
, but it's going to require flipping the |1=
and |2=
parameters of its extant instances.I'm mentioning this here at WT:MOSACCESS because a few years ago, accessibility concerns (I think in regard to particular user agents) were raised about this entire class of template/element/attribute. While this TfM will not do anything about that, it might change the loci of the issue(s); and they probably need re-examination anyway, since so much time as passed. — SMcCandlish ☏ ¢ 😼 00:29, 4 December 2020 (UTC)
— SMcCandlish ☏ ¢ 😼 00:29, 4 December 2020 (UTC)
See #New tooltip testcases, below. — SMcCandlish ☏ ¢ 😼 10:12, 14 December 2020 (UTC)
Users of screen-readers, I've set up some new tests at
Template:Tooltip/testcases, to see about having
Template:Sronly provide a workaround for title=
tooltips to make them accessible. If this works as well in practice as it does in testing so far, this is probably the way out of the problem of tooltips being used and being inaccessible, but the community by and large just ignoring the accessibility issues and doing it anyway. It's better to just fix the problem technologically than to try to continue arm-twisting editors (who mostly don't read guidelines anyway) into doing something they don't want to.
If this does work well, then
Wikipedia:Templates for discussion/Log/2020 December 11#Template:Hover title and Template:Tooltip is still ongoing. This is a merge proposal of some tooltip templates (that do not abuse the <abbr>...</abbr>
element), but before the above mentioned {{
sronly}}
work were objected to as
MOS:TOOLTIP problems. And, if this does work well, that guideline section will need updating, as will various templates that have for years used tooltips despite what the guideline section has been saying. —
SMcCandlish
☏
¢ 😼
10:12, 14 December 2020 (UTC)
I have had multiple editors utter those words in recent weeks. I think it was a mistake to move this under the MOS page way back when (24 May 2010). Multiple parts of it are expected to be followed outside of main space. Most especially LISTGAP of course (talk pages are a PITA), but there are other parts that are just good sense.
Would anyone find it palatable to move this back out to WP:Accessibility? -- Izno ( talk) 05:41, 6 December 2020 (UTC)
NASCARfan0548 ( talk · contribs) has been reverting changes to articles about NASCAR driver articles that I stumbled across recently. They ignore MOS:SMALLTEXT creating tables that have a font size less than 75% of baseline, and then they make some text in the table small! This is an example and this is another. NASCARfan0548 claims there is a manual of style, but has yet to point to it, so I'll open the discussion here. Walter Görlitz ( talk) 16:21, 11 September 2020 (UTC)
This restriction on the minimum font size that is acceptable in Wikipedia articles for reasons of accessibility is not negotiable, and I am wiling to sanction editors who breach the guideline without good reason once they have been made aware of MOS:FONTSIZE. -- RexxS ( talk) 13:57, 12 September 2020 (UTC)Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that
<small>...</small>
tags, and templates such as{{ small}}
and{{ smaller}}
, should not be applied to already-reduced text within those elements. Under no circumstances should the resulting font size of any text drop below 85% of the page's default font size (i.e. 11.9 px in Vector skin or 10.8 px in Monobook).
Has anyone worked with this project to get them to line-up with font sizing? Walter Görlitz ( talk) 02:29, 17 December 2020 (UTC)
Regarding horizonal vs vertical and the number of overall cells, I only edit team sports, where we don't break down an individual's stats on a per-game basis, or itemize each opponent for each season. We summaraize the season, and die-hard fans can always go to external stat sites with more detailed info. Do non-team sports or motorsports need to be different? At a minimum, those tables going off the screen is even worse on mobile devices.— Bagumba ( talk) 06:11, 17 December 2020 (UTC)
I don't really have a good idea where to go for this one: a group of users interested in CSS changes on the site. Since Edokter left, it's not really obvious to me who has CSS knowledge and will weigh in on questions of whether a CSS change/use is a good one (opinionated people are sometimes useful ;).
For example, here's some things to think about:
-- Izno ( talk) 22:04, 20 December 2020 (UTC)
Fred Gandt ·
talk ·
contribs
01:44, 21 December 2020 (UTC)The loose rules we traditionally use in core are:
Use as desired. — TheDJ ( talk • contribs) 20:51, 22 December 2020 (UTC)
I've also taken a short look at the TfD's mentioned. I find it a typical example of the problem of technical work within the English Wikipedia community. "We don't know, so lets not encourage change because it might break something". The precautionary principle works very badly if only very few users have enough background to participate. It demotivates those who DO want to work on this and causes eternally stale technical status quo. This is why i generally just change things that I know should be changed. Its better to ask forgiveness, and all that. Once templates are not in use, they are easy to delete ;) — TheDJ ( talk • contribs) 21:22, 22 December 2020 (UTC)
Rather than post it in the middle of all that, TFDs submitted for the column templates at Wikipedia:Templates for discussion/Log/2021 January 8. -- Izno ( talk) 06:28, 8 January 2021 (UTC)
2020_coronavirus_pandemic_in_Ontario has a section that renders as just headings with Javascript disabled. Likely due to violation of WP:COLLAPSE. As that page is semi-protected I can't fix it myself, and an edit request on its own talk page has had no effect. — Preceding unsigned comment added by 70.52.178.195 ( talk) 23:46, 17 January 2021 (UTC)
{{Graph:}}
extension, documented at
mw:Extension:Graph. Unfortunately, with JavaScript switched off, the extension does not render anything. The guidance at
mw:Extension:Graph #User defined fallback suggests using an image to be displayed if there is no client-side JavaScript, but I don't suppose anybody will want to generate 10 fresh images and upload them every day after already putting all the work into providing the graph version. --
RexxS (
talk)
00:38, 18 January 2021 (UTC)
<script>/* Javascript goes here */<noscript>Shows when Javascript is off</noscript></script>
fallback="filename"
attribute on the <graph>
tag) until a new service is implemented. --
RexxS (
talk)
19:03, 18 January 2021 (UTC)I want Wikipedia fixed to the specificationsThis will not happen on any timeline you can affect besides the method already provided (to wit, fix it yourself) unless you are willing to correct the code per the Phabricator tasks identified above. Period and end of story. -- Izno ( talk) 04:27, 21 January 2021 (UTC)
Fred Gandt ·
talk ·
contribs
03:54, 22 January 2021 (UTC)Wikipedia:WikiProject Discographies has an RFC for a possible alternative format for singles discography tables. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Heartfox ( talk) 01:32, 22 January 2021 (UTC)
I could've sworn I read it somewhere, but now I'm unable to find it. Any help? -- Ineffablebookkeeper ( talk) 16:55, 27 January 2021 (UTC)
I'd like to request assistance on a few discussions that could either use a gentler hand than mine or which are generally relevant to this talk page:
-- Izno ( talk) 18:21, 21 February 2021 (UTC)
I recently came across skewed text on one editor's User and User talk pages and was surprised that
WP:ACCESSIBILITY didn't cover that. We have guidelines on font color and size, and
WP:TPG says to Avoid excessive use of color and other font gimmicks
, but I think that vertigo-inducing elements should be specifically disallowed site-wide.
The pages are
User:Zoozaz1 and
User talk:Zoozaz1, which originally looked like
this and
this. The editor has added a way to opt out of the skewed text, but I don't think an average person is going to notice that.
Woodroar (
talk)
00:47, 28 February 2021 (UTC)
-moz-transform:
property (which is recognised only by Mozilla browsers) and the -webkit-transform:
property (which is recognised only by Webkit browsers). Since these properties are browser-specific, any other browser will show the text unchanged. As far as screen readers are concerned, the effect is nil. --
Redrose64 🌹 (
talk)
09:07, 1 March 2021 (UTC)For anyone who is interested, there is currently some intense discussion at the above talk page about tables that are gross violations of MOS access. It is clear that knowledge about accessibility and basic standards of web accessibility are not well understood by the average/casual editor.
If anyone has any additional expertise in this area and would like to comment, please feel free. ≫ Lil-Unique1 -{ Talk }- 20:26, 6 March 2021 (UTC)
I just reverted one change by SMcCandlish which was factually inaccurate. I almost reverted the entire bunch, because there were a lot of changes that were dubious and a matter of one person's opinion. These changes really ought to be discussed beforehand.
The change I reverted contained this:
This is not ideal, because it tells screen readers that there is a list item consisting of "Text here", then another list item that is empty, then a third list item consisting of "More text", when really these are all intended to be a single item in most cases. Because it is faulty markup, various editors will actually remove such empty list-item lines when they are encountered.
That displays a fundamental misunderstanding of how screen readers and the MediaWiki parser work. Screen readers read the rendered html, not wiki-text, and the MediaWiki parser completely removes empty list items from the html. This is the example being considered:
: Text here
:
: More text
This is what it produces:
Anyone can use the browser inspect function to see that the html produced has a list with only two items, and a screen reader will "see" a list with two items, not three as claimed.
The real point of the "pseudo-blank" line is for editors to more easily find the start of a contribution in threaded discussion in wikitext. The guidance is there to stop editors from breaking the list by placing a blank line before adding their comment. It is not intended for editors to separate out parts of their contribution and so the "new-paragraph markup on the same output line" is not helpful advice. I understand that SMcCandlish thinks that sticking html like <p>
is the best idea since sliced bread, but many editors deprecate the use of raw html in wiki-text, and there are better solutions available than re-writing most of the page in html. We have wiki-markup for a reason.
It's quite important when changing guidance to be sure of the changes, and it's courteous to other editors not to do a dozen consecutive, unrelated, undiscussed changes in one batch. -- RexxS ( talk) 02:14, 8 February 2021 (UTC)
<html><head><title>Empty list item test</title></head><body>
<ul><li>List item 1</li><li></li><li>List item 3</li></ul></body></html>
The HTML specs, and most if not all browsers interpreting them, will not "innately" suppress an empty list item; we're just depending on MW to suppress display of empty ones. Because this is at the whim of the devs, who sometimes do weird stuff, we probably shouldn't depend on this blank-item-suppression behavior being a permanent feature.
But even if we did make that assumption, this is all a "just fix it" matter. We don't need to have a big thread about this sort of wording glitch, much less mass-reverting of various unrelated changes. The section was still wrong to suggest this blank :
line approach is the only approach. It's a viable choice when but only when the actual intent is two distinct list items. More often than not that isn't the intent at all; it's usually done by editors making long posts and trying to use it for purely visual paragraph breaking and spacing. It's the obviously incorrect approach for that (para. breaks inside the list item are the correct one), so we should be clear on what the difference is. I've now done that, and re-instated the other stuff nuked in your revert. "We have wiki-markup for a reason": Yes, to create simple wiki documents, primarily for sighted users. It was never developed with accessibility in mind, much less to double as a discussion-board threading mechanism. About half the stuff in MOS:ACCESS is just working around lack of foresight on the part of WMF. It's irrelevant that you don't like HTML markup in posts; the exact same effect can be had with {{
pb}}
for those who prefer templates. Using HTML selectively can make the source much more readable, and give the writer more certain control over the output, but it's entirely optional.
—
SMcCandlish
☏
¢ 😼
03:02, 8 February 2021 (UTC); revised: 03:27, 8 February 2021 (UTC)
<li class="mw-empty-elt"></li>
for empty list items in ordered and unordered lists (whether created through explicit HTML or with *
and #
markup). So they are still present, and we're depending on the user agent to accept a CSS class's instruction to suppress rendering (which may be a reasonable dependency/assumption these days, even for screen readers). However, with description lists (i.e., what our talk discussions are mostly structured with), the browser receives a raw <dd></dd>
, which is exactly what you said is not happening.The important thing for this segment of this MoS page is whether :
as a blank "spacer" line is actually going to produce an annoying "nothing" list item in screen readers, or will just be skipped by them. I don't think it really matters who did less testing than they should have (seems to be both of us!) I suspect that them being skipped is actually true, but
Graham87, who seems to test-drive a lot of screen readers, can probably confirm one way or the other. Regardless, the blank item not existing in what MW sends to the browser can't be a factor (because it does exist in what the browser receives after all, and not even with CSS class aimed at hiding it). And the blank-:
-line technique, even if it works, is still the wrong one to use for most cases because they're intended to be single posts (single list items).
—
SMcCandlish
☏
¢ 😼
03:27, 8 February 2021 (UTC)
which may be a reasonable dependency/assumption these days, even for screen readersGraham has verified as such of late. -- Izno ( talk) 03:43, 8 February 2021 (UTC)
:
line between comments of editor A and editor B at the same indentation level. And I changed the <p>...</p>
example to use {{
pb}}
since it's more wiki and less HTMLy. :-) —
SMcCandlish
☏
¢ 😼
03:54, 8 February 2021 (UTC)
display:none
. That removes it from the DOM tree for both browsers and screen readers, and that's why nobody sees or hears it, but it's visible in the source code. My point about how it's not voiced by screen readers still stands. I also stand by my assertion that preceding a contribution by a pseudo-blank line is the only viable advice to give to editors who wish to make their post appear more separate from others in the wikitext. --
RexxS (
talk)
04:26, 8 February 2021 (UTC)
new section
) or add an uninformative one (c
, comment
, r
, reply
), then having it default, for replies, to Reply
, seems reasonable to me. I just looked through about 40 or 50 edits to talk pages, and I found only one informative, non-automated edit summary for a reply. That editor had simply copied and pasted his entire comment into the edit summary field. Almost everything else was either absent or automated.This is over my head and I don't know if what I'm about to say is relevant, but I previewed the following in a sandbox:
: Text here : : More text
Viewing the HTML source showed:
<dl><dd>Text here</dd> <dd></dd> <dd>More text</dd></dl>
Johnuniq ( talk) 06:15, 8 February 2021 (UTC)
Please see: Wikipedia talk:Manual of Style/Tables#Conflicting guidance on headers, which concerns MOS guidance on "year" and "title" columns in tables (specifically, which column should be the rowheader, and the ordering of the two columns). — Goszei ( talk) 06:36, 24 March 2021 (UTC)
rowspan
and accessibilty, as well. —
SMcCandlish
☏
¢ 😼
10:12, 3 April 2021 (UTC)I recently came across List of highest-grossing films#Highest-grossing franchises and film series, which surprised me in the number of accounts on which it violated this guideline, mostly through Template:Highest-grossing films franchise, which is used in 21 other articles. I thought someone here might want to take a crack at improving it. Nardog ( talk) 01:02, 7 April 2021 (UTC)
Iran11y and Psychoslave ran a test of the French Wikipedia using Orca (assistive technology). The report is at m:Accessibility of Wikipedia, a March 2021 use test session. I think it may be interesting to the regulars here as well as to the MediaWiki devs. Whatamidoing (WMF) ( talk) 01:06, 9 April 2021 (UTC)
Pages watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles. Izno ( talk) 01:08, 23 April 2021 (UTC)
I tried the following:
* '''Agree''' because of
** Reason 1
** Reason 2 {{pb}} This should be a new paragraph in this vote after the sublist.
It renders as follows:
The new paragraph shows as a paragraph in the second item of the sublist. This is not what I want. Dominic Mayers ( talk) 22:06, 23 April 2021 (UTC)
<dl>...</dl>
element, containing a single <dd>...</dd>
element, itself containing a block of text within which is a <ul>...</ul>
element. The closing </li>
tags are not required in HTML5, but they make it neater. --
Redrose64 🌹 (
talk)
23:00, 23 April 2021 (UTC)
HTML can be very explicit about the scope of each item, exactly as you mean semantically. You want:
This should be a new paragraph in this vote after the sublist.
so the "This..." goes outside the close of the sub-list but still within the list-item of the main list. DMacks ( talk) 02:43, 27 May 2021 (UTC)
When designing our tables at Tennis Project six or seven years ago, we were told over and over by wikipedia accessibility patrols never to use ! mid table. It was only to be used at the top as a header. It became problematic for some screen readers to see new headers in an unusual place and it was not proper html. Plus editors started using it as a replacement for bolding in tables. Example:
We redesigned many tables based on this info from WP:accessibility and it was confirmed by those who used screen readers. No problems. But now I see scope being used with ! at the start of a new row. Did something change with screen readers to allow the ! with the term scope? Shouldn't even scope be used with | throughout the table? In the example style above we also found editors incorrectly using ! to simply bold terms and grey in cells with a non-standard grey that didn't match |- style="font-weight:bold; background:#efefef;". We corrected all our tables at Tennis Project to conform but now I see editors using an exclamation point with the scope term. Does using "scope" fix all these issues with the exclamation point? Thanks. Fyunck(click) ( talk) 19:16, 28 May 2021 (UTC)
scope=
attribute to show what the header cell is the header for: scope=col
means that it is the header for all of the data cells below it in the same column, whilst scope=row
means that it is the header for all of the data cells to its right in the same row. If omitted, scope=col
is assumed.! scope="row" |
. --
Gonnym (
talk)
07:50, 29 May 2021 (UTC)
That will be up to the project.- this sounds like WP:LOCALCONSENSUS. Please do not compromise the semantics of the page for the sake of visual appearance. -- Redrose64 🌹 ( talk) 19:14, 29 May 2021 (UTC)
ACCESS is not a local consensus. It would apply to all of the English project. We can address when other projects choose to ignore accessibility issues. Walter Görlitz ( talk) 19:16, 29 May 2021 (UTC)
it is not even required that it be a headeris just wrong. Headers should be headers. That's why you should use the exclamation point (!) in wikicode for all the header cells. It produces
<th>
cells in the HTML. The "scope" is to clarify whether the th cell is a column heading or a row heading. They are not optional or mix-and-match. I don't think (although I'm not 100% sure) that the scope
attributes even have any effect on a <td>
cell.th
and td
elements share most of their attributes - what is valid for one is usually valid for the other, but scope=
is an exception, being only valid for a <th>
tag. The corresponding attribute for a <td>
tag is
the headers=
attribute, but that's much more complicated to use. --
Redrose64 🌹 (
talk)
22:29, 29 May 2021 (UTC)
headers=
, but haven't had the pleasure of trying to use it. —
JohnFromPinckney (
talk /
edits)
22:32, 29 May 2021 (UTC)I've got a question about
WP:ACCIM. How or does it apply to the use of images such as
File:Symbol venus.svg in articles like
Astronaut birthplaces by US state? FWIW, I totally get the visual appeal of using the symbol next to the names of women astronauts, but at the same time it seems a bit cluttery and not really necessary for encyclopedic reasons since all of the individuals listed have a stand-alone article written about them. My main concern is though is whether it creates access issues for visually impaired or maybe even those looking at the moblie version of the article. Are there any such issues which need to be addressed? Does anyone know how a
screen reader might treat such an image? Does it just say the file's name when it comes to it or does it say something like "female"? I know that there's an |alt=
parameter that can be used in the image syntax, but that doesn't seem to be the case with respect to this article. --
Marchjuly (
talk)
00:46, 20 June 2021 (UTC)
Page watchers may be interested in WT:MOS#NavFrame removal (soon). Izno ( talk) 21:50, 28 July 2021 (UTC)
See Talk:Pangaea#Animation_of_Pangaea_breakup there is a discussion about whether a gif is in violation of accessibility guidelines. Hemiauchenia ( talk) 16:51, 8 August 2021 (UTC)
I've noticed that the episode templates on our articles about TV shows can be problematic. These problems tend to fall into two categories: either the text is colored such that is in unreadable on dark mode wikipedia app, such as this example, or portions of the text flat out doesnt appear example of missing titles and another missing titles. I dont know if this is a fault of poor color choice, an oversight in the templates, or an issue with the mobile app itself. Thanks, L3X1 ◊distænt write◊ 15:30, 21 May 2021 (UTC)
I have noticed that there still a few templates that require fixed image sizes. Examples are {{ wide image}}, {{ tall image}}, {{ panorama}} and {{ panorama 2}}. There are also infoboxes, such as {{ infobox football biography}}. I have commented at the latter, but do not have the skill to modify these templates, not to mention the issues about converting all of the pixel sizes to relative sizes. Granted, the templates I have listed here are usually larger anyhow, so they may not need to change. Walter Görlitz ( talk) 20:46, 8 September 2021 (UTC)
You are invited to join the discussion at
Talk:List of screw drives § Images in Section Headings. —
Marchjuly (
talk)
04:09, 15 October 2021 (UTC)
It is my hope that this new shortcut will end up being used instead of MOS:LISTGAP. My reason for creating it is a discussion I had a while back that went something like this:
Now obviously editor 2 there could've taken a different approach and explained that we were talking about accessibility, not just style, or I could have followed the link and read the section and realized it for myself, but maybe this will help avoid future misunderstandings of this nature. Beeblebrox ( talk) 22:53, 21 November 2021 (UTC)
I went ahead and deleted the one I made, there obciously does not need to be yet another shortcut for the same section, but I would still prefer something that made it clear that this is an accessability issue as opposed to a matter of house style. Beeblebrox ( talk) 00:19, 23 November 2021 (UTC)
I'm updating some of the symbol galleries on commons, and tried gallery style="background-color: black"
. However, while that adds a black background to the gallery as a whole, each cell still has a white background. How can I change the latter? (The images themselves have a transparent background, that's not the issue.)
Thanks — kwami ( talk) 02:46, 4 January 2022 (UTC)
mode=nolines
. —
kwami (
talk)
09:57, 4 January 2022 (UTC)I'm at a loss for what to do with this one ... and fixing it might require a lot of manual work. Basically it uses bullet characters instead of proper HTML list markup, which affects screen reader users like me because it makes it more difficult to move between list items, and it probably abuses layout tables. I've added alt text to the male/female pictograms, once I figured out what they were actually for, but the other issues should be addressed as well. Graham 87 15:36, 4 January 2022 (UTC)
I was wondering if the font size (min 0.85x normal font size) also applies to images. In particular, would this figure at effects of climate change be in line with accessibility guidelines? I would argue it's an accessibility issue, but of course, it's possible to enlarge images by clicking on them.. Femke ( talk) 10:57, 15 January 2022 (UTC)
upright=1.75
to match a picture gallery.)—
RCraig09 (
talk)
19:53, 18 January 2022 (UTC)There is a discussion at WikiProject Weather regarding the accessibility of track maps, templates/infoboxes, and timelines for the colorblind community. Feedback would be appreciated. Noah Talk 22:04, 21 March 2022 (UTC)
Hi all,
So there was an RfC on the suggestion to place a space beneath each heading (
see here), which I initiated in order to have the option to add a single line of space underneath a section heading without necessarily needing to add another edit yet. I often times "prime" an article first by adding these spaces, and then it is easier for me to read, and then I make the appropriate edits (of a typo, grammatical or other "gnome-like" fix). Another editor took issue with this, and thus a RfC was born. The conclusion of that RfC suggested for a conversation to take place here, in this talk page, with this guidance, Editors are invited to discuss how to phrase an appropriate edit to MOS:ACCESS that would explain the benefits of leaving a white line after headings for visually impaired people, and also the drawbacks for small-screen users. When the phrasing is agreed, the appropriate edit may be made.
. Let the "discussion" commence now.
. ♥
Th78blue (
talk)♥
13:02, 31 March 2022 (UTC)
For anyone concerned, the guidance has now been updated. Zindor ( talk) 00:18, 10 April 2022 (UTC)
You are invited to join the discussion at
Talk:Takuya Nagase § Bundling citations.
Marchjuly (
talk)
15:10, 30 April 2022 (UTC)
As written, Wikipedia:LISTGAP offers no way to break a long bulleted paragraph into two separate paragraphs (with the second one unbulleted). Is there a way to do this? If not, is there some other good strategy for dealing with a "wall of text" bullet item? - Butwhatdoiknow ( talk) 16:52, 8 May 2022 (UTC)
{{
pb}}
.Like this. --
Redrose64 🌹 (
talk)
21:57, 8 May 2022 (UTC)
User:Redrose64, your most recent edit cites to wp:LISTGAP, which does not discuss "*:" vs. "::". That discussion is at MOS:INDENTMIX. Should we add text to LISTGAP to point to the INDENTMIX discussion (similar to this edit)?. - Butwhatdoiknow ( talk) 20:08, 9 May 2022 (UTC)
Page watchers may be interested in Template talk:Information#General style of template (and use of mbox class). Please leave any comments there. Izno ( talk) 03:51, 18 May 2022 (UTC)
I was checking this page on my phone, through the app, after the iPhone decided it was late enough to go to night vision--with the black background. The long and short of it, accessibility is gone--in 2023_FIFA_Women's_World_Cup_qualification#Knockout_stage, the scores seem to be white numbers on a white background; in 2023_FIFA_Women's_World_Cup_qualification#Knockout_stage, "Played" and "points" are white against a light-green and light-blue background, and are practically illegible. I'm already doubtful about whether the page fulfills MOS:COLOR in terms of contrast on my laptop, but what's happening on my phone is just unacceptable. Where is the problem? In the switch made by the phone for night vision, or with our colors--or both? Drmies ( talk) 02:47, 15 July 2022 (UTC)
The following is said to be incorrect
* Support. I like this idea. —User:Example
:* Question: What do you like about it? —User:Example2
What about this
:Here is a list of people I know:
:* John
:* Peter —User1
:: @User1, Why do you give this list? —User2
The logic is that User2 wants to reply to the entire comment of User1, not only to the last item in the list, which will be the case in
:Here is a list of people I know:
:* John
:* Peter —User1
:*: @User1, Why do you give this list? —User2
nor does he want to stay at the same level of indentation as the previous comment to which he replies as in
:Here is a list of people I know:
:* John
:* Peter —User1
:@User1, Why do you give this list? —User2
By the way, I know that the problem would be avoided if User1 would sign outside the list as in
:Here is a list of people I know:
:* John
:* Peter
:—User1
:: @User1, Why do you give this list? —User2
However, it is very common that a list ends with a sublist.
If passing from * to : is a problem, a simple solution would be to add an intermediary item as in
:Here is a list of people I know:
:* John
:* Peter —User1
:
:: @User1, Why do you give this list? —User2
However, I really want to know if it is necessary to add this intermediary item to avoid passing directly from * to : . I suspect that the first example given is only incorrect because the machine would not understand that the item :* is a question about the previous item *. Therefore, it may be the case that passing from :* to :: is correct if the intention is not to reply to the previous item :*, but to reply to the overall item :. Dominic Mayers ( talk) 12:34, 18 July 2022 (UTC)
:Here is a list of people I know:
:* John
:* Peter —User1
:: @User1, Why do you give this list? —User2
:Here is a list of people I know:
:* John
:* Peter —User1
:
:: @User1, Why do you give this list? —User2
A discussion was started at Module talk:RoundN § Medal colors for gold/silver/bronze, aiming to change the module's background colors in favor of more accessible ones. Please, join us in it, as we lack experience in the subject. CLalgo ( talk) 19:30, 26 July 2022 (UTC)
All,
A bit uncertain whether I'm doing this right. For the table at Los Angeles Chargers#Pro Football Hall of Famers will it work correctly for the screen reader as I have it, or would the phrase "San Diego / Los Angeles Chargers Hall of Famers" be read out twice in a row? Thanks in advance for any assistance. Harper J. Cole ( talk) 23:48, 26 July 2022 (UTC)
See the documentation for {{ anchor}} and MOS:HEADINGS for why this is an issue. As I just learned, {{ subst:lang}} does not really work, but at the same time leaving untagged non-English content in section headings creates an accessibility issue. While rewording to avoid the non-English content may work in many cases, the subsections in articles like Spanish personal pronouns#Regional variation really should be tagged. I'm wondering if there's some guidance available, and if so, whether this MOS page should link to it in some manner. Thanks in advance! 69.174.144.79 ( talk) 17:02, 28 July 2022 (UTC)
Is it still true that embedding an image inside a list introduces a break, separating the single list into two lists? If so, should the MOS say not to do this? Example:
Looking at the html it seems this may have been fixed? GA-RT-22 ( talk) 15:05, 2 August 2022 (UTC)
@ GA-RT-22: Your example places the image inside the first list item, which is permitted, although the alt text and caption will be read out following the textual part of the first list item and before the second list item is announced, so it's best to ensure that the image is directly relevant to that particular list item. A better form might be to place the image at the start of the list item, but still inside it:
Markup | Renders as |
---|---|
* [[File:Westminstpalace.jpg|thumb|upright=.5|alt=Alt text|Caption text]] First item preceded by image * Second item |
|
This follows the advice to place images before the text that refers to them. However, back to the point. The advice to which you refer concerns markup like this:
Markup | Renders as |
---|---|
* First item followed by image [[File:Westminstpalace.jpg|thumb|upright=.5|alt=Alt text|Caption text]] * Second item |
|
This is two separate one-item lists with an image between. Apart from having separate lists, it is not clear whether the image relates to the first item or to the "second" item. -- Redrose64 🌹 ( talk) 23:11, 2 August 2022 (UTC)
I've noticed a lack of thought when it comes to people who have comprehension and reading issues as of late in most articles, including newer ones, if the goal of Wikipedia is to help the general public learn about most of the time quite wordy information than should we not be bolding key words in articles? Sauriazoicillus ( talk) 01:18, 8 August 2022 (UTC)
In buryat wikipedia horizontal lists doesn't work as intented and unbulleted lists are with bullets. What is the problem? 66.181.187.130 ( talk) 16:53, 10 August 2022 (UTC)
The section of this page covering colour and contrast seems to be primarily focused on text and data tables, but it seems to me that this is equally relevant to images. An image intended to illustrate an article should ideally have good contrast for visually-impaired and colourblind readers just as it should have good alt text for blind readers. A picture of a red phone box in front of a field of green grass would be an archetypal example of an image with this sort of problem where the issue may not be intuitively apparent to the majority of editors. I am unsure what amendments would be warranted here, if any at all, but a plainly worded statement on the matter could be helpful. HumanBodyPiloter5 ( talk) 17:33, 14 August 2022 (UTC)
Courtesy link:
List of French monarchs
In this question at Help desk, I asked about testing alt text. This is probably a better venue for that question. Moxy suggested dispenser's Altviewer, which seems to work. Wondered what solutions you use? Thanks, Mathglot ( talk) 01:45, 19 August 2022 (UTC)
I had brought this up elsewhere and I wanted to make sure there were no accessibility issues. I came across some bold markup that looks strange but seems to work fine visually. I have no idea if it causes problems with JAWS or other aids for sight-challenged and there seems to be no wikipedia rules on where you should or shouldn't place bold markup. Two ways of formatting bold in some articles is:
Both styles are prevalent throughout Wikipedia. Both give the same visual display on my laptop... the flagicon does not get visually bolded. Does using the bold markup before the flagicon template cause any issues or weirdness with screen readers, etc? Thanks. Fyunck(click) ( talk) 08:56, 8 September 2022 (UTC)
Is it legitimate to introduce blank lines in the displayed list by using the {{sp}} spacing template? E.g.
* A longish entry
{{sp}}
* Another entry...
I would have thought not but it is done in the current edit of Mormon abuse cases#Selected LDS Church cases.
Best wishes, Pol098 ( talk) 19:50, 8 September 2022 (UTC)
* A longish entry<br><br>
* Another entry<br><br>...
![]() | This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Feedback requested at Wikipedia_talk:Manual_of_Style#Typographical_symbols_used_for_notes_and_accessibility. Thanks. ― Justin (koavf)❤ T☮ C☺ M☯ 02:03, 21 March 2020 (UTC)
Need help with advanced coding so we don't deter potential new editors because they can't see pages properly. Pls see Wikipedia talk:WikiProject Accessibility#Another module tutorial with accessibility problems.-- Moxy 🍁 16:03, 7 April 2020 (UTC)
Our document says We aim to adhere to Web Content Accessibility Guidelines 2.0
Should we be developing to 2.0 or 2.1 of Web Content Accessibility Guidelines? 2.1 came out in June 2018 ( new in 2.1). I took a quick glance in the archives and didn't see anything about this, apologies if I missed the discussion. Kees08 (Talk) 15:59, 7 April 2020 (UTC)
Should tables always include a caption? -- RexxS ( talk) 21:41, 6 April 2020 (UTC)
In most popular screen readers, it is possible to bring up a (voiced) list of all of the table captions on a page. That then allows the screen reader user to navigate directly to the table that they want to read.
As Graham87 has explained, if a table has no caption, then JAWS will voice the first column heading to 'identify' the table. We really should not be letting that happen, so there is an implicit expectation that a table will have a caption.
Graham also tells me that it's common for a screen reader user to navigate by calling up a list of headings and use that to navigate to the section that they want. That has lead us to accept tables without captions where the table comes immediately below a heading and the caption would simply duplicate that heading. That's a concession to sighted editors who don't like the look of repeated text – simply an aesthetic consideration. Nevertheless that still leaves screen reader users who navigate via tables with the issue of hearing the first column title instead of a sensible caption, so it's less than ideal.
I am requesting comments from editors with the intention to include a phrase along the lines of "Tables should always include a caption" in the guidance at Wikipedia:Manual of Style/Accessibility #Data tables if the RfC results in support for that. To be clear: this would mean that captions should be included in data tables, even when the table immediately follows a heading which would duplicate the caption. -- RexxS ( talk) 21:41, 6 April 2020 (UTC)
I've placed at notice at WP:CENT and at Wikipedia talk:WikiProject Accessibility. -- RexxS ( talk) 21:56, 6 April 2020 (UTC)
Please confine threaded discussion to the discussion section.
>>
BEANS X2
t
10:54, 20 April 2020 (UTC)As I said above, I reluctantly oppose this RFC as worded too broadly. Template:Navbox, for example, uses table markup, but unless I am mistaken (which happens regularly), it provides neither a caption nor a summary. How would our navboxes be modified to have a caption? If this is a straw man, feel free to set it on fire; I'm just looking at what comes out of Special:ExpandTemplates when I put Template:AKB48 or pretty much any other navbox in it. – Jonesey95 ( talk) 23:51, 6 April 2020 (UTC)
so I really don't think this RfC can possibly have any bearing on the use of tables for layout. -- RexxS ( talk) 00:07, 7 April 2020 (UTC)When using a table to position non-tabular content, help screen readers identify it as a layout table, not a data table. Set a
role="presentation"
attribute on the table, and do not set anysummary
attribute. Do not use any<caption>
or<th>
elements inside the table, or inside any nested tables.
"I am requesting comments from editors with the intention to include a phrase along the lines of "Tables should always include a caption" in the guidance at Wikipedia:Manual of Style/Accessibility #Data tables"and I don't think that could be any clearer. I won't try to persuade you to change your opposition, as it should be sufficient for the closer of the RfC to determine the community's consensus on what wording would be appropriate and the context to which it applies. -- RexxS ( talk) 00:33, 7 April 2020 (UTC)
@ NinjaRobotPirate: Hi, I was wondering if there were any specific exceptions that apply that you were thinking of. I am sure there could be exceptions, but I was hoping we could clear up if a similarly worded section header directly above the table could be considered an exception. Did you mean that case, or other exceptions we may not be thinking of? I suppose the proposal is clear, as it says To be clear: this would mean that captions should be included in tables, even when the table immediately follows a heading which would duplicate the caption, but I wanted to make sure you saw that. Thanks! Kees08 (Talk) 15:42, 7 April 2020 (UTC)
Outside of Wikipedia, I assume that formal papers generally expect tables to have a caption. My guess is in WP that
Now that people are realizing the accessibility issues, some might be reticent to reword (or remove) those legacy headers that would sound repetive by adding the table captions (that ideally would have been used to begin with). Preferably, we would address accessibility while minimizing the effort to retrofit headers. For example, Eagles247 and Koavf found a way for {{ NFL roster}} at User_talk:Koavf/Archive055#Template:NFL_roster to retrofit an existing template to move existing display text to the caption with no visual difference for sighted readers. This is not always possible, depending on the template.— Bagumba ( talk) 17:29, 9 April 2020 (UTC)
The oppose from Jweiss11 typifies the flawed argument "We've been ignoring the needs of the visually impaired for years, so we should be free to carry on doing it." There's no recognition that aesthetic issues such as a caption repeating a header are very minor compared to the need for screen reader users to have a sensible way of navigating to a particular table. Consider 1901 Michigan Wolverines football team#Schedule where editors leave screen reader users to identify that table as "Date". There's absolutely no reason why Module:CFB schedule should not add a caption tag at line 360. Consider Fielding H. Yost#Head coaching record where screen reader users need to navigate to the table called "Year". How unhelpful is that? What does it really matter if we take the trouble to put "Head coaching record" as the heading and the table caption? Would the table even need its own section if the table had a proper caption? -- RexxS ( talk) 22:56, 9 April 2020 (UTC)
"Has anyone explained why we can't have a field just for the screenreaders to solve this problem without creating redundant text in the standard displays?"There are no fields. The caption text is not redundant, and there are no standard displays. For the blind, there are no displays at all. If you read the discussion, you'll find that I already created a template Template:Sronly that seems to be able to instruct modern browsers not to display a piece of text, while allowing screen readers to voice that text.
The RfC will expire within 48 hours, and is probably ripe for closure anyway. I suggest that we ask an uninvolved administrator or experienced user to close this RfC as the question poses a significant change to prior practice.
Should the RfC result in support for the question, I would like the closer to confirm a form of words for the guideline that best represent the consensus expressed in the debate. My suggestion would be adding the following sentence to the end of the Caption section in Wikipedia:Manual of Style/Accessibility #Data tables:
I suggest that anyone should feel free to suggest alternative wording, but please don't re-legislate the entire discussion. We should be trying to help the closer, not convince them of our own view. Cheers -- RexxS ( talk) 22:40, 4 May 2020 (UTC)
A quick follow-on related to this: I noticed that the default "insert table" button in the wikitext editor does not include a caption element by default, and have filed phab:T252350 so that new tables added this way are encouraged to include a caption. The VisualEditor insert table option does already include space for a caption. the wub "?!" 21:54, 10 May 2020 (UTC)
This addition does not seem useful to me. It moves from accessibility advice into style advice, and small tags are useful for reasons other than semantic purposes, like shrinking the second line of an infobox title (larger by default) so that it shows as normal-sized text. I'm sure there are other examples. – Jonesey95 ( talk) 22:48, 16 April 2020 (UTC)
At Wikipedia:Manual of Style/Accessibility#Text there is guidance on transliterations:
Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
It's not clear how to do this. It would be very helpful if there were examples. For instance, should the transliteration appear following the non-Latin text and appear in parentheses? Coastside ( talk) 19:43, 13 May 2020 (UTC)
Do things like UEFA Euro 2020#Venues cause problems? First, they're fixed size. Second it's a type of gallery. Third, they're in oddly formatted tables. Fourth, no alt text. Walter Görlitz ( talk) 18:27, 18 May 2020 (UTC)
![]() |
---|
Wembley Stadium |
Capacity: 90,000 |
![]() |
![]() |
---|
Allianz Arena |
Capacity: 75,000 |
![]() |
![]() |
---|
Stadio Olimpico |
Capacity: 72,698 |
![]() |
![]() |
---|
Olympic Stadium |
Capacity: 68,700 |
![]() |
![]() |
---|
Krestovsky Stadium |
Capacity: 68,134 |
![]() |
![]() |
---|
Puskás Aréna |
Capacity: 67,215 |
![]() |
![]() |
---|
Arena Națională |
Capacity: 55,600 |
![]() |
![]() |
---|
Johan Cruyff Arena |
Capacity: 54,990 |
![]() |
![]() |
---|
Hampden Park |
Capacity: 52,063 |
![]() |
![]() |
---|
Aviva Stadium |
Capacity: 51,700 |
|
![]() |
---|
Parken Stadium |
Capacity: 38,065 |
|
There is an rfc on the layout of tables listing adult entertainment awards, and I recognised an accessibility issue with the reading order of the table headers for a screen reader. Wikipedia_talk:WikiProject_Pornography#rfc_49102E2 I referred to WP:ACCESSIBILITY, but then realised there is no advisory on headers and reading order in the section about data tables for people to refer to. Morbidthoughts ( talk) 07:51, 20 May 2020 (UTC)
I'm not sure where I read it, but I read that there were issues with some screen readers and tables that used rowspans. Has this been resolved or are we even seeking resolution? They are heavily used in articles about musicians and sportspeople. I'm curious if we should be approaching those projects or if a larger consensus needs to be reached. Walter Görlitz ( talk) 06:30, 12 May 2020 (UTC)
{{
shade|75%}}
being obvious culprits. --
RexxS (
talk)
19:58, 12 May 2020 (UTC)
Per MOS:TABLECAPTION, all data tables should have captions leading them. Sometimes, the captions are pretty bare-bones, such as "Records by season" or "Albums", whereas I am of the opinion that they should be descriptive enough to stand on their own--i.e. "[Sports team] records by season" or "[Recording artist] albums". My thinking here is two-fold: 1.) the function of a caption is to describe the contents of the table, so unless a table is about the concept of records by season or generally about albums, it's necessary to add these caveats and 2.) sometimes, these tables are inserted into other articles--e.g. with many lists of television series episodes--so there are times when the context is not quite as obvious as when the table is included in [sports team]'s or [recording artist]'s bios. Thoughts on best practices here and any language we can use at MOS:TABLECAPTION to make the best practices clear? ― Justin (koavf)❤ T☮ C☺ M☯ 04:33, 27 May 2020 (UTC)
Is there any guidance on forcing linebreaks within infobox parameters that are not lists? See for example |office6=
on
Nancy Pelosi, but there are many more - seems to be particularly common in uses of {{
infobox officeholder}}. If this is something to be avoided I suggest it would be worthwhile to explicitly say so in this guideline.
Nikkimaria (
talk)
21:27, 29 May 2020 (UTC)
Is this discouraged under MOS:LISTGAP? That is, does it cause the problems for screen readers described there?
: I like this idea. [[User:Example]] * I don't like this idea. [[User:Example 2]] : I don't like this discussion. [[User:Example 3]]
― Mandruss ☎ 15:36, 19 May 2020 (UTC)
: I like this idea. [[User:Example]]
: I don't like this idea. [[User:Example 2]]
: I don't like this discussion. [[User:Example 3]]
* I like this idea. [[User:Example]]
* I don't like this idea. [[User:Example 2]]
* I don't like this discussion. [[User:Example 3]]
: I like this idea. [[User:Example]]
:* I don't like this idea. [[User:Example 2]]
: I don't like this discussion. [[User:Example 3]]
"Likewise, do not switch between initial list marker types (colons, asterisks or hash signs) in one list". It is principally about screen readers and I wrote an essay on it at WP:Colons and asterisks. -- RexxS ( talk) 18:25, 19 May 2020 (UTC)
I'm starting this discussion. [[User:Example]]
* I don't like this discussion. [[User:Example 3]]
"For example, in a discussion, do this best practice:"which seems to me to refer to discussions, as does
"When indenting in reply ...". Nevertheless if you can improve the wording, why not do it? I'd be interested to see what your additional example is. -- RexxS ( talk) 18:55, 19 May 2020 (UTC)
@ RexxS: The following could be the last example at LISTGAP:
nor this (use asterisk in an unbulleted thread):
I have an idea. [[User:Example]] * What is it? [[User:Example 2]]
― Mandruss ☎ 19:03, 19 May 2020 (UTC)
*
though. --
RexxS (
talk)
19:11, 19 May 2020 (UTC)
*
. The first poster that uses an indent creates a list and that's what needs to be preserved. Period. --
RexxS (
talk)
20:32, 19 May 2020 (UTC)
What if we could have discussions that aren’t lists?
I’m imagining something like:
I think the article could benefit from more images. [[User:Joe Bloggs.]] dtstamp {{ind1|p| No way! There are already too many scattered across multiple sections. [[User:N.A. Sayer.]] dtstamp }} {{ind2|p| {{re|N.A. Sayer}} We could move them to a gallery. [[User:Valerie G.]] dtstamp }}
Which could render as:
<p>I think the article could benefit from more images. <a href=...>User:Joe Bloggs.</a> dtstamp</p> <p class=mw-indent-1>No way! There are already too many scattered across multiple sections. <a href=...>User:N.A. Sayer.</a> dtstamp</p> <p class=mw-indent-2>@<a href=...>N.A. Sayer<a>: We could move them to a gallery. <a href=...>User:Valerie G.</a> dtstamp</p>
With CSS like:
.mw-indent-1 margin-left:2em; /* or 5vw, or whatever */ .mw-indent-2 margin-left:4em;
[I won’t go into the HTML5 idea of comments as sequences of (article(footer))(article(footer))... elements. And bulleted or numbered responses would still be lists, I guess.]
What would it mean for screenreaders and accessibility in general if our conversations were paragraphs (or similar) rather than lists?
— Pelagic ( messages ) Z – (22:51 Mon 01, AEST) 12:51, 1 June 2020 (UTC)
<dd><dd><dd><dd><dd>This is my 2¢</dd></dd></dd></dd></dd>
is an abomination, in so many ways.
Pelagic (
messages )
Z – (22:51 Mon 01, AEST)
12:51, 1 June 2020 (UTC)
i have been adding lang
template for person names, cities, college or journal titles on foreign wikis (es,de,pt etc.) am i doing right by adding template ?
Vishnuvardhan leela (
talk)
01:35, 15 June 2020 (UTC)
I have made a proposal for an accessibility feature for Wikipedia here - Wikipedia:Village pump (idea lab)/Archive 31#Colour text options - and I would love to hear the views of people involved in this project. Helper201 ( talk) 00:22, 24 June 2020 (UTC)
I was adding a caption to a table on a video game page, and realized that {{ Video game reviews}} (used on 10,000+ pages) didn't have a "caption" element; in looking at it, though, I'm not sure it's meeting ACCESS requirements besides that? Example at Final Fantasy XII#Reception. It has a "header row" that acts as a caption, and then three sub-tables that have a data row as a header, then a header row for column headers (no colscopes), then data rows for the data (no rowscopes). I can add col/rowscopes to the subtables, and convert the top-level header to a caption, but I'm not sure that it works for screen readers even with that. Can anyone confirm if it does/doesn't work as currently designed? -- Pres N 14:55, 29 June 2020 (UTC)
<figure>
<figcaption>Reception</figcaption>
<table><!-- one for each kind of data -->
<caption>Aggregator scores</caption>
<tr><th>Aggregator</th><th>Score</th></tr><!-- with scopes of course -->
<tr><td><!--maybe could be a th with row scope, though I tend toward td -->Agg1</td><td>Score1</td></tr>
<tr><td>AggN</td><td>ScoreN</td></tr>
</table>
<table><!-- ditto for reviews -->
<caption>Publication scores</caption>
...
</table>
<table><!-- ditto for awards -->
<caption>Awards</caption>
...
</table>
</figure>
A discussion is taking place to address the redirect
MOS:SMALL. The discussion will occur at
Wikipedia:Redirects for discussion/Log/2020 July 3#MOS:SMALL until a consensus is reached, and readers of this page are welcome to contribute to the discussion. –
Davey2010
Talk
18:03, 3 July 2020 (UTC)
User Koavf has decided to slow-burn-edit-war this, but I'm starting the discussion instead of following their very poor example.
It's unclear to me whether the editor seeks to allow "small" in infoboxes, etc, provided it's for "fine print". If so, they are effectively saying accessibility is unimportant for this "fine print", and I would strongly disagree. If not, the ambiguity needs to be cleared up. Either way, the sentence is so vague as to be fairly pointless; if somebody wants a piece of text smaller, they need only call it "fine print" to satisfy the guideline as written. Wikipedia content is not legal contracts. Finally, there's a WP:CREEP issue, and I don't know that hairs need to be split quite this finely. ― Mandruss ☎ 00:16, 30 June 2020 (UTC)
<small>...</small>
just to create a visual effect for any campaign of fixing the semantics to be successful. Most editors don't understand that the the 'small' tag carries a meaning for some users and re-users, and almost certainly don't care. --
RexxS (
talk)
12:49, 6 July 2020 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I'm experiencing inappropriate pushback at Docklands Light Railway rolling stock. Two editors ( C2A06 and user:Thryduulf) are insisting that the combination of {{ DLR color}} (#00B2A9) with white text is "easier to read" than the template-chosen black. I've explained that the color contrast with white fails all four WCAG accessibility criteria, and provided a link to the color tool proving this: https://snook.ca/technical/colour_contrast/colour.html#fg=FFFFFF,bg=00B2A9 However, these editors continue to revert and ask for "discussion" . It's completely inappropriate to leave the article in a state which violates WP:COLOR. See discussion at Talk:Docklands_Light_Railway_rolling_stock#Infobox_color>— TAnthony Talk 03:10, 22 July 2020 (UTC)
Such as {{ Kintetsu Minami-Osaka Line}}. Should this be formally prohibited?-- GZWDer ( talk) 20:33, 10 August 2020 (UTC)
The s element represents contents that are no longer accurate or no longer relevant.This is a correct use of that element. -- Izno ( talk) 20:52, 10 August 2020 (UTC)
I know that over the years I've seen editors in the wild removing excessive rowspans from tables (See the language column) because of concerns that screen readers have trouble presenting the content, but I don't see anything in the guidelines that looks like an official stance on this. Am I missing something? Can the community clarify this in the MOS? Thanks, Cyphoidbomb ( talk) 16:25, 15 August 2020 (UTC)
People who understand table formatting may want to look at Wikipedia:Village pump (technical)#Expanding class=wikitable to make tables accessible to blind, and to align cell text. Whatamidoing (WMF) ( talk) 02:26, 20 August 2020 (UTC)
I have been watching as an editor has added game results to Portland Timbers–Vancouver Whitecaps rivalry and am worried about the accessibility of the tables that have resulted. I have not run it through a checker, but would like some advice, preferably on the article's talk page. Walter Görlitz ( talk) 23:37, 4 September 2020 (UTC)
Please see: Wikipedia talk:Manual of Style/Captions#Video timestamps. Involves how to specify times in A/V material: "4:31", "4 min 31 sec", "4 m. 31 s.", etc., etc. — SMcCandlish ☏ ¢ 😼 12:20, 26 October 2020 (UTC)
Please see:
— SMcCandlish ☏ ¢ 😼 05:35, 17 November 2020 (UTC)
On Template talk:Tick#Alt text we are discussing the most appropriate alt text for the check mark. Any comments would be welcome over there. — Martin ( MSGJ · talk) 20:08, 18 November 2020 (UTC)
Please see:
Wikipedia talk:WikiProject Disability/Style guide#Requested move 20 November 2020
—
SMcCandlish
☏
¢ 😼
20:51, 28 November 2020 (UTC)
Hi editors, I was directed to this page in my peer review. It is for a band, and it was brought up that the timeline for band members was not accessible as it relied only on colour to show information. I have added a letter code here to the timeline for better accessibility, but I was wondering if someone might have any further feedback about how to make the timeline better? Typically band timelines have just been published with just a colour code. Thanks in advance. SatDis ( talk) 08:10, 5 December 2020 (UTC)
Some of the advice about screen readers seems to be out of date and not literally correct. For example,
Do not use unpronounceable symbols such as ♥ (a heart symbol)
Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
Do not use Unicode characters as icons; use an icon with alt text instead. For example, a character like "→" cannot be reproduced into useful text by a screen reader and will usually be read as a question mark.
I just tried these in Apple’s VoiceOver (I am not a regular user). It reads them as “red heart suit,” “dagger” (while the recommended {{ †}} says “dagger image”), and “right arrow.”
I will adjust the corresponding text to say “often unpronounceable” and “might not.” — Michael Z. 16:37, 11 December 2020 (UTC)
{{†|alt=whatever you want}}
gives †, which says "whatever you want". Being able to specify what the dagger indicates is a considerable advantage over the symbol.It's not a good idea. I can't read the hearts symbol with JAWS." Now, it is true that screen readers have improved over the past ten years, but the most popular reader, JAWS, costs around $1,000 and many users may still be running older versions, so unless you're sure that the vast majority of screen readers used on Wikipedia can read those symbols (which I doubt you can claim), we ought to stick with unequivocal advice. -- RexxS ( talk) 17:45, 11 December 2020 (UTC)
"an image, an image of text or a pictorial or decorative character symbol (glyph) which imparts information nonverbally"(which is why I considered it was referring to non-ascii characters) and it recommends that
"an image with a text alternative can be used instead of the glyph."In my experience, the issue tends to be found in tables or lists where a compact marker is used either to represent a longer piece of text (♥ = "hearts suit"), or designate something († = "Captain").
Please see: Wikipedia:Templates for discussion/Log/2020 December 3#Template:Hover title and Template:Tooltip
Summary:
{{
Abbr}}
(a wrapper for <abbr>...</abbr>
) has long been abused for non-abbreviation markup (against the HTML specs).{{
Tooltip}}
, with <span>...</span>
for non-abbreviation use, but it was "merged" (not really) and redirected to {{Abbr}}
.{{
Hover title}}
was created to do the same thing, but with backwards parameters (and some additional features).{{Tooltip}}
then-redirect and {{
Hover title}}
template have been transcluded in tens of thousands of articles, mainly via infoboxes and other templates.{{
Tooltip}}
template, with all the features of {{Hover title}}
but preserving the {{
Abbr}}
parameter order (to not break deployed translcusions).{{
Hover title}}
, but it's going to require flipping the |1=
and |2=
parameters of its extant instances.I'm mentioning this here at WT:MOSACCESS because a few years ago, accessibility concerns (I think in regard to particular user agents) were raised about this entire class of template/element/attribute. While this TfM will not do anything about that, it might change the loci of the issue(s); and they probably need re-examination anyway, since so much time as passed. — SMcCandlish ☏ ¢ 😼 00:29, 4 December 2020 (UTC)
— SMcCandlish ☏ ¢ 😼 00:29, 4 December 2020 (UTC)
See #New tooltip testcases, below. — SMcCandlish ☏ ¢ 😼 10:12, 14 December 2020 (UTC)
Users of screen-readers, I've set up some new tests at
Template:Tooltip/testcases, to see about having
Template:Sronly provide a workaround for title=
tooltips to make them accessible. If this works as well in practice as it does in testing so far, this is probably the way out of the problem of tooltips being used and being inaccessible, but the community by and large just ignoring the accessibility issues and doing it anyway. It's better to just fix the problem technologically than to try to continue arm-twisting editors (who mostly don't read guidelines anyway) into doing something they don't want to.
If this does work well, then
Wikipedia:Templates for discussion/Log/2020 December 11#Template:Hover title and Template:Tooltip is still ongoing. This is a merge proposal of some tooltip templates (that do not abuse the <abbr>...</abbr>
element), but before the above mentioned {{
sronly}}
work were objected to as
MOS:TOOLTIP problems. And, if this does work well, that guideline section will need updating, as will various templates that have for years used tooltips despite what the guideline section has been saying. —
SMcCandlish
☏
¢ 😼
10:12, 14 December 2020 (UTC)
I have had multiple editors utter those words in recent weeks. I think it was a mistake to move this under the MOS page way back when (24 May 2010). Multiple parts of it are expected to be followed outside of main space. Most especially LISTGAP of course (talk pages are a PITA), but there are other parts that are just good sense.
Would anyone find it palatable to move this back out to WP:Accessibility? -- Izno ( talk) 05:41, 6 December 2020 (UTC)
NASCARfan0548 ( talk · contribs) has been reverting changes to articles about NASCAR driver articles that I stumbled across recently. They ignore MOS:SMALLTEXT creating tables that have a font size less than 75% of baseline, and then they make some text in the table small! This is an example and this is another. NASCARfan0548 claims there is a manual of style, but has yet to point to it, so I'll open the discussion here. Walter Görlitz ( talk) 16:21, 11 September 2020 (UTC)
This restriction on the minimum font size that is acceptable in Wikipedia articles for reasons of accessibility is not negotiable, and I am wiling to sanction editors who breach the guideline without good reason once they have been made aware of MOS:FONTSIZE. -- RexxS ( talk) 13:57, 12 September 2020 (UTC)Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that
<small>...</small>
tags, and templates such as{{ small}}
and{{ smaller}}
, should not be applied to already-reduced text within those elements. Under no circumstances should the resulting font size of any text drop below 85% of the page's default font size (i.e. 11.9 px in Vector skin or 10.8 px in Monobook).
Has anyone worked with this project to get them to line-up with font sizing? Walter Görlitz ( talk) 02:29, 17 December 2020 (UTC)
Regarding horizonal vs vertical and the number of overall cells, I only edit team sports, where we don't break down an individual's stats on a per-game basis, or itemize each opponent for each season. We summaraize the season, and die-hard fans can always go to external stat sites with more detailed info. Do non-team sports or motorsports need to be different? At a minimum, those tables going off the screen is even worse on mobile devices.— Bagumba ( talk) 06:11, 17 December 2020 (UTC)
I don't really have a good idea where to go for this one: a group of users interested in CSS changes on the site. Since Edokter left, it's not really obvious to me who has CSS knowledge and will weigh in on questions of whether a CSS change/use is a good one (opinionated people are sometimes useful ;).
For example, here's some things to think about:
-- Izno ( talk) 22:04, 20 December 2020 (UTC)
Fred Gandt ·
talk ·
contribs
01:44, 21 December 2020 (UTC)The loose rules we traditionally use in core are:
Use as desired. — TheDJ ( talk • contribs) 20:51, 22 December 2020 (UTC)
I've also taken a short look at the TfD's mentioned. I find it a typical example of the problem of technical work within the English Wikipedia community. "We don't know, so lets not encourage change because it might break something". The precautionary principle works very badly if only very few users have enough background to participate. It demotivates those who DO want to work on this and causes eternally stale technical status quo. This is why i generally just change things that I know should be changed. Its better to ask forgiveness, and all that. Once templates are not in use, they are easy to delete ;) — TheDJ ( talk • contribs) 21:22, 22 December 2020 (UTC)
Rather than post it in the middle of all that, TFDs submitted for the column templates at Wikipedia:Templates for discussion/Log/2021 January 8. -- Izno ( talk) 06:28, 8 January 2021 (UTC)
2020_coronavirus_pandemic_in_Ontario has a section that renders as just headings with Javascript disabled. Likely due to violation of WP:COLLAPSE. As that page is semi-protected I can't fix it myself, and an edit request on its own talk page has had no effect. — Preceding unsigned comment added by 70.52.178.195 ( talk) 23:46, 17 January 2021 (UTC)
{{Graph:}}
extension, documented at
mw:Extension:Graph. Unfortunately, with JavaScript switched off, the extension does not render anything. The guidance at
mw:Extension:Graph #User defined fallback suggests using an image to be displayed if there is no client-side JavaScript, but I don't suppose anybody will want to generate 10 fresh images and upload them every day after already putting all the work into providing the graph version. --
RexxS (
talk)
00:38, 18 January 2021 (UTC)
<script>/* Javascript goes here */<noscript>Shows when Javascript is off</noscript></script>
fallback="filename"
attribute on the <graph>
tag) until a new service is implemented. --
RexxS (
talk)
19:03, 18 January 2021 (UTC)I want Wikipedia fixed to the specificationsThis will not happen on any timeline you can affect besides the method already provided (to wit, fix it yourself) unless you are willing to correct the code per the Phabricator tasks identified above. Period and end of story. -- Izno ( talk) 04:27, 21 January 2021 (UTC)
Fred Gandt ·
talk ·
contribs
03:54, 22 January 2021 (UTC)Wikipedia:WikiProject Discographies has an RFC for a possible alternative format for singles discography tables. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Heartfox ( talk) 01:32, 22 January 2021 (UTC)
I could've sworn I read it somewhere, but now I'm unable to find it. Any help? -- Ineffablebookkeeper ( talk) 16:55, 27 January 2021 (UTC)
I'd like to request assistance on a few discussions that could either use a gentler hand than mine or which are generally relevant to this talk page:
-- Izno ( talk) 18:21, 21 February 2021 (UTC)
I recently came across skewed text on one editor's User and User talk pages and was surprised that
WP:ACCESSIBILITY didn't cover that. We have guidelines on font color and size, and
WP:TPG says to Avoid excessive use of color and other font gimmicks
, but I think that vertigo-inducing elements should be specifically disallowed site-wide.
The pages are
User:Zoozaz1 and
User talk:Zoozaz1, which originally looked like
this and
this. The editor has added a way to opt out of the skewed text, but I don't think an average person is going to notice that.
Woodroar (
talk)
00:47, 28 February 2021 (UTC)
-moz-transform:
property (which is recognised only by Mozilla browsers) and the -webkit-transform:
property (which is recognised only by Webkit browsers). Since these properties are browser-specific, any other browser will show the text unchanged. As far as screen readers are concerned, the effect is nil. --
Redrose64 🌹 (
talk)
09:07, 1 March 2021 (UTC)For anyone who is interested, there is currently some intense discussion at the above talk page about tables that are gross violations of MOS access. It is clear that knowledge about accessibility and basic standards of web accessibility are not well understood by the average/casual editor.
If anyone has any additional expertise in this area and would like to comment, please feel free. ≫ Lil-Unique1 -{ Talk }- 20:26, 6 March 2021 (UTC)
I just reverted one change by SMcCandlish which was factually inaccurate. I almost reverted the entire bunch, because there were a lot of changes that were dubious and a matter of one person's opinion. These changes really ought to be discussed beforehand.
The change I reverted contained this:
This is not ideal, because it tells screen readers that there is a list item consisting of "Text here", then another list item that is empty, then a third list item consisting of "More text", when really these are all intended to be a single item in most cases. Because it is faulty markup, various editors will actually remove such empty list-item lines when they are encountered.
That displays a fundamental misunderstanding of how screen readers and the MediaWiki parser work. Screen readers read the rendered html, not wiki-text, and the MediaWiki parser completely removes empty list items from the html. This is the example being considered:
: Text here
:
: More text
This is what it produces:
Anyone can use the browser inspect function to see that the html produced has a list with only two items, and a screen reader will "see" a list with two items, not three as claimed.
The real point of the "pseudo-blank" line is for editors to more easily find the start of a contribution in threaded discussion in wikitext. The guidance is there to stop editors from breaking the list by placing a blank line before adding their comment. It is not intended for editors to separate out parts of their contribution and so the "new-paragraph markup on the same output line" is not helpful advice. I understand that SMcCandlish thinks that sticking html like <p>
is the best idea since sliced bread, but many editors deprecate the use of raw html in wiki-text, and there are better solutions available than re-writing most of the page in html. We have wiki-markup for a reason.
It's quite important when changing guidance to be sure of the changes, and it's courteous to other editors not to do a dozen consecutive, unrelated, undiscussed changes in one batch. -- RexxS ( talk) 02:14, 8 February 2021 (UTC)
<html><head><title>Empty list item test</title></head><body>
<ul><li>List item 1</li><li></li><li>List item 3</li></ul></body></html>
The HTML specs, and most if not all browsers interpreting them, will not "innately" suppress an empty list item; we're just depending on MW to suppress display of empty ones. Because this is at the whim of the devs, who sometimes do weird stuff, we probably shouldn't depend on this blank-item-suppression behavior being a permanent feature.
But even if we did make that assumption, this is all a "just fix it" matter. We don't need to have a big thread about this sort of wording glitch, much less mass-reverting of various unrelated changes. The section was still wrong to suggest this blank :
line approach is the only approach. It's a viable choice when but only when the actual intent is two distinct list items. More often than not that isn't the intent at all; it's usually done by editors making long posts and trying to use it for purely visual paragraph breaking and spacing. It's the obviously incorrect approach for that (para. breaks inside the list item are the correct one), so we should be clear on what the difference is. I've now done that, and re-instated the other stuff nuked in your revert. "We have wiki-markup for a reason": Yes, to create simple wiki documents, primarily for sighted users. It was never developed with accessibility in mind, much less to double as a discussion-board threading mechanism. About half the stuff in MOS:ACCESS is just working around lack of foresight on the part of WMF. It's irrelevant that you don't like HTML markup in posts; the exact same effect can be had with {{
pb}}
for those who prefer templates. Using HTML selectively can make the source much more readable, and give the writer more certain control over the output, but it's entirely optional.
—
SMcCandlish
☏
¢ 😼
03:02, 8 February 2021 (UTC); revised: 03:27, 8 February 2021 (UTC)
<li class="mw-empty-elt"></li>
for empty list items in ordered and unordered lists (whether created through explicit HTML or with *
and #
markup). So they are still present, and we're depending on the user agent to accept a CSS class's instruction to suppress rendering (which may be a reasonable dependency/assumption these days, even for screen readers). However, with description lists (i.e., what our talk discussions are mostly structured with), the browser receives a raw <dd></dd>
, which is exactly what you said is not happening.The important thing for this segment of this MoS page is whether :
as a blank "spacer" line is actually going to produce an annoying "nothing" list item in screen readers, or will just be skipped by them. I don't think it really matters who did less testing than they should have (seems to be both of us!) I suspect that them being skipped is actually true, but
Graham87, who seems to test-drive a lot of screen readers, can probably confirm one way or the other. Regardless, the blank item not existing in what MW sends to the browser can't be a factor (because it does exist in what the browser receives after all, and not even with CSS class aimed at hiding it). And the blank-:
-line technique, even if it works, is still the wrong one to use for most cases because they're intended to be single posts (single list items).
—
SMcCandlish
☏
¢ 😼
03:27, 8 February 2021 (UTC)
which may be a reasonable dependency/assumption these days, even for screen readersGraham has verified as such of late. -- Izno ( talk) 03:43, 8 February 2021 (UTC)
:
line between comments of editor A and editor B at the same indentation level. And I changed the <p>...</p>
example to use {{
pb}}
since it's more wiki and less HTMLy. :-) —
SMcCandlish
☏
¢ 😼
03:54, 8 February 2021 (UTC)
display:none
. That removes it from the DOM tree for both browsers and screen readers, and that's why nobody sees or hears it, but it's visible in the source code. My point about how it's not voiced by screen readers still stands. I also stand by my assertion that preceding a contribution by a pseudo-blank line is the only viable advice to give to editors who wish to make their post appear more separate from others in the wikitext. --
RexxS (
talk)
04:26, 8 February 2021 (UTC)
new section
) or add an uninformative one (c
, comment
, r
, reply
), then having it default, for replies, to Reply
, seems reasonable to me. I just looked through about 40 or 50 edits to talk pages, and I found only one informative, non-automated edit summary for a reply. That editor had simply copied and pasted his entire comment into the edit summary field. Almost everything else was either absent or automated.This is over my head and I don't know if what I'm about to say is relevant, but I previewed the following in a sandbox:
: Text here : : More text
Viewing the HTML source showed:
<dl><dd>Text here</dd> <dd></dd> <dd>More text</dd></dl>
Johnuniq ( talk) 06:15, 8 February 2021 (UTC)
Please see: Wikipedia talk:Manual of Style/Tables#Conflicting guidance on headers, which concerns MOS guidance on "year" and "title" columns in tables (specifically, which column should be the rowheader, and the ordering of the two columns). — Goszei ( talk) 06:36, 24 March 2021 (UTC)
rowspan
and accessibilty, as well. —
SMcCandlish
☏
¢ 😼
10:12, 3 April 2021 (UTC)I recently came across List of highest-grossing films#Highest-grossing franchises and film series, which surprised me in the number of accounts on which it violated this guideline, mostly through Template:Highest-grossing films franchise, which is used in 21 other articles. I thought someone here might want to take a crack at improving it. Nardog ( talk) 01:02, 7 April 2021 (UTC)
Iran11y and Psychoslave ran a test of the French Wikipedia using Orca (assistive technology). The report is at m:Accessibility of Wikipedia, a March 2021 use test session. I think it may be interesting to the regulars here as well as to the MediaWiki devs. Whatamidoing (WMF) ( talk) 01:06, 9 April 2021 (UTC)
Pages watchers may be interested in MediaWiki talk:Common.css § Preview warning and hatnotes moving to TemplateStyles. Izno ( talk) 01:08, 23 April 2021 (UTC)
I tried the following:
* '''Agree''' because of
** Reason 1
** Reason 2 {{pb}} This should be a new paragraph in this vote after the sublist.
It renders as follows:
The new paragraph shows as a paragraph in the second item of the sublist. This is not what I want. Dominic Mayers ( talk) 22:06, 23 April 2021 (UTC)
<dl>...</dl>
element, containing a single <dd>...</dd>
element, itself containing a block of text within which is a <ul>...</ul>
element. The closing </li>
tags are not required in HTML5, but they make it neater. --
Redrose64 🌹 (
talk)
23:00, 23 April 2021 (UTC)
HTML can be very explicit about the scope of each item, exactly as you mean semantically. You want:
This should be a new paragraph in this vote after the sublist.
so the "This..." goes outside the close of the sub-list but still within the list-item of the main list. DMacks ( talk) 02:43, 27 May 2021 (UTC)
When designing our tables at Tennis Project six or seven years ago, we were told over and over by wikipedia accessibility patrols never to use ! mid table. It was only to be used at the top as a header. It became problematic for some screen readers to see new headers in an unusual place and it was not proper html. Plus editors started using it as a replacement for bolding in tables. Example:
We redesigned many tables based on this info from WP:accessibility and it was confirmed by those who used screen readers. No problems. But now I see scope being used with ! at the start of a new row. Did something change with screen readers to allow the ! with the term scope? Shouldn't even scope be used with | throughout the table? In the example style above we also found editors incorrectly using ! to simply bold terms and grey in cells with a non-standard grey that didn't match |- style="font-weight:bold; background:#efefef;". We corrected all our tables at Tennis Project to conform but now I see editors using an exclamation point with the scope term. Does using "scope" fix all these issues with the exclamation point? Thanks. Fyunck(click) ( talk) 19:16, 28 May 2021 (UTC)
scope=
attribute to show what the header cell is the header for: scope=col
means that it is the header for all of the data cells below it in the same column, whilst scope=row
means that it is the header for all of the data cells to its right in the same row. If omitted, scope=col
is assumed.! scope="row" |
. --
Gonnym (
talk)
07:50, 29 May 2021 (UTC)
That will be up to the project.- this sounds like WP:LOCALCONSENSUS. Please do not compromise the semantics of the page for the sake of visual appearance. -- Redrose64 🌹 ( talk) 19:14, 29 May 2021 (UTC)
ACCESS is not a local consensus. It would apply to all of the English project. We can address when other projects choose to ignore accessibility issues. Walter Görlitz ( talk) 19:16, 29 May 2021 (UTC)
it is not even required that it be a headeris just wrong. Headers should be headers. That's why you should use the exclamation point (!) in wikicode for all the header cells. It produces
<th>
cells in the HTML. The "scope" is to clarify whether the th cell is a column heading or a row heading. They are not optional or mix-and-match. I don't think (although I'm not 100% sure) that the scope
attributes even have any effect on a <td>
cell.th
and td
elements share most of their attributes - what is valid for one is usually valid for the other, but scope=
is an exception, being only valid for a <th>
tag. The corresponding attribute for a <td>
tag is
the headers=
attribute, but that's much more complicated to use. --
Redrose64 🌹 (
talk)
22:29, 29 May 2021 (UTC)
headers=
, but haven't had the pleasure of trying to use it. —
JohnFromPinckney (
talk /
edits)
22:32, 29 May 2021 (UTC)I've got a question about
WP:ACCIM. How or does it apply to the use of images such as
File:Symbol venus.svg in articles like
Astronaut birthplaces by US state? FWIW, I totally get the visual appeal of using the symbol next to the names of women astronauts, but at the same time it seems a bit cluttery and not really necessary for encyclopedic reasons since all of the individuals listed have a stand-alone article written about them. My main concern is though is whether it creates access issues for visually impaired or maybe even those looking at the moblie version of the article. Are there any such issues which need to be addressed? Does anyone know how a
screen reader might treat such an image? Does it just say the file's name when it comes to it or does it say something like "female"? I know that there's an |alt=
parameter that can be used in the image syntax, but that doesn't seem to be the case with respect to this article. --
Marchjuly (
talk)
00:46, 20 June 2021 (UTC)
Page watchers may be interested in WT:MOS#NavFrame removal (soon). Izno ( talk) 21:50, 28 July 2021 (UTC)
See Talk:Pangaea#Animation_of_Pangaea_breakup there is a discussion about whether a gif is in violation of accessibility guidelines. Hemiauchenia ( talk) 16:51, 8 August 2021 (UTC)
I've noticed that the episode templates on our articles about TV shows can be problematic. These problems tend to fall into two categories: either the text is colored such that is in unreadable on dark mode wikipedia app, such as this example, or portions of the text flat out doesnt appear example of missing titles and another missing titles. I dont know if this is a fault of poor color choice, an oversight in the templates, or an issue with the mobile app itself. Thanks, L3X1 ◊distænt write◊ 15:30, 21 May 2021 (UTC)
I have noticed that there still a few templates that require fixed image sizes. Examples are {{ wide image}}, {{ tall image}}, {{ panorama}} and {{ panorama 2}}. There are also infoboxes, such as {{ infobox football biography}}. I have commented at the latter, but do not have the skill to modify these templates, not to mention the issues about converting all of the pixel sizes to relative sizes. Granted, the templates I have listed here are usually larger anyhow, so they may not need to change. Walter Görlitz ( talk) 20:46, 8 September 2021 (UTC)
You are invited to join the discussion at
Talk:List of screw drives § Images in Section Headings. —
Marchjuly (
talk)
04:09, 15 October 2021 (UTC)
It is my hope that this new shortcut will end up being used instead of MOS:LISTGAP. My reason for creating it is a discussion I had a while back that went something like this:
Now obviously editor 2 there could've taken a different approach and explained that we were talking about accessibility, not just style, or I could have followed the link and read the section and realized it for myself, but maybe this will help avoid future misunderstandings of this nature. Beeblebrox ( talk) 22:53, 21 November 2021 (UTC)
I went ahead and deleted the one I made, there obciously does not need to be yet another shortcut for the same section, but I would still prefer something that made it clear that this is an accessability issue as opposed to a matter of house style. Beeblebrox ( talk) 00:19, 23 November 2021 (UTC)
I'm updating some of the symbol galleries on commons, and tried gallery style="background-color: black"
. However, while that adds a black background to the gallery as a whole, each cell still has a white background. How can I change the latter? (The images themselves have a transparent background, that's not the issue.)
Thanks — kwami ( talk) 02:46, 4 January 2022 (UTC)
mode=nolines
. —
kwami (
talk)
09:57, 4 January 2022 (UTC)I'm at a loss for what to do with this one ... and fixing it might require a lot of manual work. Basically it uses bullet characters instead of proper HTML list markup, which affects screen reader users like me because it makes it more difficult to move between list items, and it probably abuses layout tables. I've added alt text to the male/female pictograms, once I figured out what they were actually for, but the other issues should be addressed as well. Graham 87 15:36, 4 January 2022 (UTC)
I was wondering if the font size (min 0.85x normal font size) also applies to images. In particular, would this figure at effects of climate change be in line with accessibility guidelines? I would argue it's an accessibility issue, but of course, it's possible to enlarge images by clicking on them.. Femke ( talk) 10:57, 15 January 2022 (UTC)
upright=1.75
to match a picture gallery.)—
RCraig09 (
talk)
19:53, 18 January 2022 (UTC)There is a discussion at WikiProject Weather regarding the accessibility of track maps, templates/infoboxes, and timelines for the colorblind community. Feedback would be appreciated. Noah Talk 22:04, 21 March 2022 (UTC)
Hi all,
So there was an RfC on the suggestion to place a space beneath each heading (
see here), which I initiated in order to have the option to add a single line of space underneath a section heading without necessarily needing to add another edit yet. I often times "prime" an article first by adding these spaces, and then it is easier for me to read, and then I make the appropriate edits (of a typo, grammatical or other "gnome-like" fix). Another editor took issue with this, and thus a RfC was born. The conclusion of that RfC suggested for a conversation to take place here, in this talk page, with this guidance, Editors are invited to discuss how to phrase an appropriate edit to MOS:ACCESS that would explain the benefits of leaving a white line after headings for visually impaired people, and also the drawbacks for small-screen users. When the phrasing is agreed, the appropriate edit may be made.
. Let the "discussion" commence now.
. ♥
Th78blue (
talk)♥
13:02, 31 March 2022 (UTC)
For anyone concerned, the guidance has now been updated. Zindor ( talk) 00:18, 10 April 2022 (UTC)
You are invited to join the discussion at
Talk:Takuya Nagase § Bundling citations.
Marchjuly (
talk)
15:10, 30 April 2022 (UTC)
As written, Wikipedia:LISTGAP offers no way to break a long bulleted paragraph into two separate paragraphs (with the second one unbulleted). Is there a way to do this? If not, is there some other good strategy for dealing with a "wall of text" bullet item? - Butwhatdoiknow ( talk) 16:52, 8 May 2022 (UTC)
{{
pb}}
.Like this. --
Redrose64 🌹 (
talk)
21:57, 8 May 2022 (UTC)
User:Redrose64, your most recent edit cites to wp:LISTGAP, which does not discuss "*:" vs. "::". That discussion is at MOS:INDENTMIX. Should we add text to LISTGAP to point to the INDENTMIX discussion (similar to this edit)?. - Butwhatdoiknow ( talk) 20:08, 9 May 2022 (UTC)
Page watchers may be interested in Template talk:Information#General style of template (and use of mbox class). Please leave any comments there. Izno ( talk) 03:51, 18 May 2022 (UTC)
I was checking this page on my phone, through the app, after the iPhone decided it was late enough to go to night vision--with the black background. The long and short of it, accessibility is gone--in 2023_FIFA_Women's_World_Cup_qualification#Knockout_stage, the scores seem to be white numbers on a white background; in 2023_FIFA_Women's_World_Cup_qualification#Knockout_stage, "Played" and "points" are white against a light-green and light-blue background, and are practically illegible. I'm already doubtful about whether the page fulfills MOS:COLOR in terms of contrast on my laptop, but what's happening on my phone is just unacceptable. Where is the problem? In the switch made by the phone for night vision, or with our colors--or both? Drmies ( talk) 02:47, 15 July 2022 (UTC)
The following is said to be incorrect
* Support. I like this idea. —User:Example
:* Question: What do you like about it? —User:Example2
What about this
:Here is a list of people I know:
:* John
:* Peter —User1
:: @User1, Why do you give this list? —User2
The logic is that User2 wants to reply to the entire comment of User1, not only to the last item in the list, which will be the case in
:Here is a list of people I know:
:* John
:* Peter —User1
:*: @User1, Why do you give this list? —User2
nor does he want to stay at the same level of indentation as the previous comment to which he replies as in
:Here is a list of people I know:
:* John
:* Peter —User1
:@User1, Why do you give this list? —User2
By the way, I know that the problem would be avoided if User1 would sign outside the list as in
:Here is a list of people I know:
:* John
:* Peter
:—User1
:: @User1, Why do you give this list? —User2
However, it is very common that a list ends with a sublist.
If passing from * to : is a problem, a simple solution would be to add an intermediary item as in
:Here is a list of people I know:
:* John
:* Peter —User1
:
:: @User1, Why do you give this list? —User2
However, I really want to know if it is necessary to add this intermediary item to avoid passing directly from * to : . I suspect that the first example given is only incorrect because the machine would not understand that the item :* is a question about the previous item *. Therefore, it may be the case that passing from :* to :: is correct if the intention is not to reply to the previous item :*, but to reply to the overall item :. Dominic Mayers ( talk) 12:34, 18 July 2022 (UTC)
:Here is a list of people I know:
:* John
:* Peter —User1
:: @User1, Why do you give this list? —User2
:Here is a list of people I know:
:* John
:* Peter —User1
:
:: @User1, Why do you give this list? —User2
A discussion was started at Module talk:RoundN § Medal colors for gold/silver/bronze, aiming to change the module's background colors in favor of more accessible ones. Please, join us in it, as we lack experience in the subject. CLalgo ( talk) 19:30, 26 July 2022 (UTC)
All,
A bit uncertain whether I'm doing this right. For the table at Los Angeles Chargers#Pro Football Hall of Famers will it work correctly for the screen reader as I have it, or would the phrase "San Diego / Los Angeles Chargers Hall of Famers" be read out twice in a row? Thanks in advance for any assistance. Harper J. Cole ( talk) 23:48, 26 July 2022 (UTC)
See the documentation for {{ anchor}} and MOS:HEADINGS for why this is an issue. As I just learned, {{ subst:lang}} does not really work, but at the same time leaving untagged non-English content in section headings creates an accessibility issue. While rewording to avoid the non-English content may work in many cases, the subsections in articles like Spanish personal pronouns#Regional variation really should be tagged. I'm wondering if there's some guidance available, and if so, whether this MOS page should link to it in some manner. Thanks in advance! 69.174.144.79 ( talk) 17:02, 28 July 2022 (UTC)
Is it still true that embedding an image inside a list introduces a break, separating the single list into two lists? If so, should the MOS say not to do this? Example:
Looking at the html it seems this may have been fixed? GA-RT-22 ( talk) 15:05, 2 August 2022 (UTC)
@ GA-RT-22: Your example places the image inside the first list item, which is permitted, although the alt text and caption will be read out following the textual part of the first list item and before the second list item is announced, so it's best to ensure that the image is directly relevant to that particular list item. A better form might be to place the image at the start of the list item, but still inside it:
Markup | Renders as |
---|---|
* [[File:Westminstpalace.jpg|thumb|upright=.5|alt=Alt text|Caption text]] First item preceded by image * Second item |
|
This follows the advice to place images before the text that refers to them. However, back to the point. The advice to which you refer concerns markup like this:
Markup | Renders as |
---|---|
* First item followed by image [[File:Westminstpalace.jpg|thumb|upright=.5|alt=Alt text|Caption text]] * Second item |
|
This is two separate one-item lists with an image between. Apart from having separate lists, it is not clear whether the image relates to the first item or to the "second" item. -- Redrose64 🌹 ( talk) 23:11, 2 August 2022 (UTC)
I've noticed a lack of thought when it comes to people who have comprehension and reading issues as of late in most articles, including newer ones, if the goal of Wikipedia is to help the general public learn about most of the time quite wordy information than should we not be bolding key words in articles? Sauriazoicillus ( talk) 01:18, 8 August 2022 (UTC)
In buryat wikipedia horizontal lists doesn't work as intented and unbulleted lists are with bullets. What is the problem? 66.181.187.130 ( talk) 16:53, 10 August 2022 (UTC)
The section of this page covering colour and contrast seems to be primarily focused on text and data tables, but it seems to me that this is equally relevant to images. An image intended to illustrate an article should ideally have good contrast for visually-impaired and colourblind readers just as it should have good alt text for blind readers. A picture of a red phone box in front of a field of green grass would be an archetypal example of an image with this sort of problem where the issue may not be intuitively apparent to the majority of editors. I am unsure what amendments would be warranted here, if any at all, but a plainly worded statement on the matter could be helpful. HumanBodyPiloter5 ( talk) 17:33, 14 August 2022 (UTC)
Courtesy link:
List of French monarchs
In this question at Help desk, I asked about testing alt text. This is probably a better venue for that question. Moxy suggested dispenser's Altviewer, which seems to work. Wondered what solutions you use? Thanks, Mathglot ( talk) 01:45, 19 August 2022 (UTC)
I had brought this up elsewhere and I wanted to make sure there were no accessibility issues. I came across some bold markup that looks strange but seems to work fine visually. I have no idea if it causes problems with JAWS or other aids for sight-challenged and there seems to be no wikipedia rules on where you should or shouldn't place bold markup. Two ways of formatting bold in some articles is:
Both styles are prevalent throughout Wikipedia. Both give the same visual display on my laptop... the flagicon does not get visually bolded. Does using the bold markup before the flagicon template cause any issues or weirdness with screen readers, etc? Thanks. Fyunck(click) ( talk) 08:56, 8 September 2022 (UTC)
Is it legitimate to introduce blank lines in the displayed list by using the {{sp}} spacing template? E.g.
* A longish entry
{{sp}}
* Another entry...
I would have thought not but it is done in the current edit of Mormon abuse cases#Selected LDS Church cases.
Best wishes, Pol098 ( talk) 19:50, 8 September 2022 (UTC)
* A longish entry<br><br>
* Another entry<br><br>...