Wikipedia talk:Manual of Style/Accessibility

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

"WT:COLOR" and "WT:COLOUR" redirect here. For WikiProject Color's talk page, see Wikipedia talk:WikiProject Color.

Accessibility of scrolling tables. Different template

Graham87. You noted in this discussion, Talk:COVID-19 pandemic deaths/Archive 1#Scrolling versus expanded tables, that the scrolling tables in the related article (COVID-19 pandemic deaths) were not a problem. You said: "it doesn't affect totally blind screen reader users." Those were a particular set of scrolling tables discussed here:

• Help:Table/Advanced#Advanced scrolling tables with sticky headers

I want to know if this is also true for the scrolling tables (from a different template) in this version of a list article with 3 scrolling tables:

• https://en.wikipedia.org/enwiki/w/index.php?title=List_of_countries_by_firearm-related_death_rate&oldid=1232941127

This method for scrolling tables is discussed here:

• Help:Table/Advanced#Table with sticky header in simple scroll window

--Timeshifter (talk) 14:22, 6 July 2024 (UTC)

@Timeshifter: They generally work fine here. The only exception is JAWS under Chrome, but I think that's a JAWS issue and not a problem with the tables per se ... the combination of JAWS and Chrome is having problems with all sorts of tables at the moment. Graham87 (talk) 14:32, 6 July 2024 (UTC)

All sticky headings use pure CSS. For screenreader users it should be just fine because of that. If anything, it's more likely to be a problem for people with partial blindness or for older users etc, as the position of the element changes, which might be confusing to some. I can also imagine that the max-height vertical scroller can be a bit of a problem for screenreader users on mobile phones, as having a vertical scroller within a vertical scroller can be confusing for discovery, but as long as there are no controls inside the vertical scroller, that too seems unlikely to cause a problem. —TheDJ (talk • contribs) 08:15, 8 July 2024 (UTC)

Collapsing on mobile

Note that mobile versions of the website do not support collapsing, so any collapsible content will automatically be uncollapsed.

This seems out of date; it works just fine on my phone or when I try the mobile preview on my computer. I'll remove it for now but let me know if anyone objects. Closed Limelike Curves (talk) 19:13, 27 July 2024 (UTC)

Alt text for images

Dear visually impaired readers of Wikipedia. I sometimes add alt text to images to aid accessibility. I aim to be as succinct as possible while also being as correct as possible. The latter goal tends to make the descriptions lengthier but I try to keep them under 250 words. I mention color because I think that's important even if some some of our visually impaired readers have been blind since birth. I am not visually impaired and I don't use screen readers. The reason I am writing is to ask for suggestions of things to avoid when writing alt text. Things that bother you in alt text that you wish the writers would not do. That way I could better understand things from the perspective of a person who uses alt text. By the way, I've also started to use AI image generators to see how well my descriptions can duplicate the image. It's an interesting experiment and the results suggest that a picture requires far far more than a thousands words to describe as is commonly said. Nevertheless, most of the time the descriptions are reasonable approximations. Jason Quinn (talk) 10:21, 13 August 2024 (UTC)

@Jason Quinn: Thanks very much for this. As a totally blind person from birth, I can't think of anything to add but I find it hard to evaluate alt text because I don't know what I'm missing; see my comments in this discussion. Graham87 (talk) 15:30, 13 August 2024 (UTC)

Alt text for icons in templates

How should a template handle alt text on an icon, if the icon can be changed? Some templates need |alt= parameters for selectable images, but what about a template where the image should be purely decorative? Should it have an |alt= parameter, or should it use the same alt text consistently?

I'm asking about general best practices but will link examples that brought this up. {{Archive}} has a little filing cabinet icon, but this can be changed to anything. An alt parameter and link parameter were added after this edit request: Template talk:Archives/Archive 1#Accessibility improvement for image. I'm thinking though that it would likely be more straightforward to just always have the alt text be something like "archiving icon". I've searched through pages that make use of the "alt" parameter. It's rarely used and when it is used, it is usually "Icon of a filing cabinet". I've listed several examples of its usage below.

Page	Alt text	Image	Description
Wikipedia talk:WikiProject Computing/Computer Programming task force/Archive Index	File:Replacement filing cabinet.svg	File:Replacement filing cabinet.svg	Icon of a filing cabinet
User talk:Jsayre64	Oregon	File:Oregon DEM relief map.gif	Small map of Oregon
Template talk:Jct	Jct	File:Jct plate.svg	License plate reading "JCT"
User talk:XAM2175/2023/06	Icon of a filing cabinet	File:Replacement filing cabinet.svg	Icon of a filing cabinet

Useful parameter or simpler to use standardized alt text regardless of icon image? Rjjⁱⁱⁱ (talk) 20:51, 23 August 2024 (UTC)

Yeah making the alt text "Archiving icon" sounds sensible to me. Graham87 (talk) 04:04, 24 August 2024 (UTC)

Purely decorative images should have no link and no alt text according to accessibility experts since ever. What's the concern with that option? Izno (talk) 04:10, 7 September 2024 (UTC)

If the template allows the image to be chosen on the page where it's used, an editor can choose an image that is not public domain or available under an equivalent license. All creative commons images need to link to the page with their attribution information. Rjjⁱⁱⁱ (talk) 04:33, 7 September 2024 (UTC)

The |alt= and |link= parameters are unrelated; the value of one does not affect the meaning of the other. Setting |link= to an empty string can be a problem. If use of the image requires attribution (this includes, but is not limited to, the CC BY and CC BY-SA licenses), we must be able to reach the file description page so that the attribution may be seen. Indeed, WP:EIS#Link says: Except for public-domain images, it must always be possible for the reader to reach the image-description page, so |link= should be used only with |thumb images. Setting |alt= to an empty string does not, of itself, violate any policies so is much less of an issue. But if Graham87 suggests |alt=Archiving icon, I would go with that 100%. --Redrose64 🌹 (talk) 09:16, 7 September 2024 (UTC)

Typically, though, there would already be a text heading or description conveying the same information. In that case, having alt text on the decorative image that replicates the text is superfluous. isaacl (talk) 15:43, 7 September 2024 (UTC)

If the image in a template like this needs to be linked for attribution, it'd be better if there was alt text on the image (despite its slight redundancy). Graham87 (talk) 09:10, 8 September 2024 (UTC)

Discussion at WP:HD § Accessibility question

 You are invited to join the discussion at WP:HD § Accessibility question. -- Marchjuly (talk) 07:40, 28 August 2024 (UTC)

Mobile skin and block quotations

Page watchers may be interested in Wikipedia talk:Manual of Style § Mobile skin and block quotations. Please feel free to participate there. Izno (talk) 04:07, 7 September 2024 (UTC)

WP:NOBR notes

are there any acceptable uses for the HTML line break <br/>? on a recent edit of mine, I substituted a {{ubl}} template into the HTML line break, as this was not being used for a list but as a visual break for the default size, separating the series title from the year in a table, for visual harmony.

I have seen this sort of visual break in many articles that I have edited, especially less cared ones, but how should it be handled? is it COMPLETELY discouraged it, even for use cases where there is legitemately no factor other than aesthetics or what to do instead? Juwan (talk) 12:21, 19 September 2024 (UTC)

Not to hock my own slogan, but essentially as I understand it, break means pause. That is to say, line breaks are acceptable when they actually represent semantic breaks in content, perhaps roughly equivalent to a paragraph break. They should neither be used to create the appearance of lists nor to manually wrap a single block of text, but beyond that there are actually plenty of plausible applications. Infobox templates themselves actually use them a lot under the hood. Remsense ‥ 论 12:24, 19 September 2024 (UTC)

oh, that's actually a great essay! if you think it is appropriate please link it on the section, that's exactly what I was looking for. Juwan (talk) 12:49, 19 September 2024 (UTC)

It's incomplete at the moment, and I like the idea that others would link such things rather than me if they find it useful so that only useful things get linked, so if you think it would help others then go for it! Remsense ‥ 论 12:56, 19 September 2024 (UTC)

Line breaks are for visual appearance only, and so semantically they are equivalent to whitespace. Appropriate semantic markup should be used as applicable. Line breaks should be used sparingly. As browser widths change or other elements are added to the page, the page will automatically be laid out differently by browsers, and manual overrides can work against this process producing a pleasing result. isaacl (talk) 18:40, 19 September 2024 (UTC)

Where to place accessibility templates on problem templates

The section on color suggests placing the {{Overcolored}} template at the top of articles with contrast issues. What about templates. For example, the {{Transport in Mexico City}} template has major issues with contrast. But if I place the template at the top of the template itself, it will appear on dozens of pages, which would be disruptive. I wound up placing it on the Transport in Mexico City template talk page at the top of my topic.

It would be good to clarify this in the text as to where it would best be placed in templates.

Thisisnotatest (talk) 06:14, 26 September 2024 (UTC)

I would put it on the doc page as well. If there's not a maintenance category for templates with accessibility issues, maybe it should be created and populated! I would personally appreciate that. Remsense ‥ 论 07:04, 26 September 2024 (UTC)

Place it in the template, either in the documentation, or if it doesn't, then at the bottom between the noinclude tags. Gonnym (talk) 08:31, 26 September 2024 (UTC)

Thank you! I've moved it to the template documentation as well as added it to a related template. That's what I will do moving forward. Thisisnotatest (talk) 07:21, 27 September 2024 (UTC)

Looping GIFs and accessibility

My edit Animations: Clarified 5 seconds as total playing time was reverted by Remsense with the comment "This is confusing to me: are looping GIFs simply not allowed?"

Rather than risking getting into an edit war, I am moving the matter here to attempt to gain consensus on wording before proposing a final edit.

WCAG 2.1 provides Technique G152: Setting animated gif images to stop blinking after n cycles (within 5 seconds)

Looping GIFs are permitted as long as they stop looping such that the total animation time is 5.0 seconds or less. So:

• A 1 second long animated GIF could loop 5 times
• A 1.5 second long animated GIF could loop 3 times
• A 2 or 2.5 second long animated GIF could only loop twice
• A 3 second long animated GIF could not loop at all
• Endlessly looping animated GIFs are not permitted at all

Hope that makes it clear (which I believe the current page wording does not do).

Thisisnotatest (talk) 07:11, 27 September 2024 (UTC)

Suffice it to say, this does require conversation as almost no one operates based on this understanding, even if it's well-founded. Remsense ‥ 论 07:13, 27 September 2024 (UTC)

From what I understand, and I'm woefully underread in the literature so this is partially anecdotal so forgive me, there is a significant distinction in accessibility between short animations that loop and long animations. SC 2.2.2: Pause, Stop, Hide says

“

Content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen readers.

Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of the Web page. Five seconds was chosen because it is long enough to get a user's attention, but not so long that a user cannot wait out the distraction if necessary to use the page.

”

The operative sentence uses the word "blinking" in a manner I find to be a bit vague: I would intuit some distinction many people would perceive between "blinking", merely "looping", and "ongoing" animated content in terms of its potential to interfere with their ability to focus or comfortably read? Later, "blinking" is defined as "content that causes a distraction problem", which is unfortunately a bit circular for our purposes. If blinking is coterminous with moving, why isn't moving used? Remsense ‥ 论 07:22, 27 September 2024 (UTC)

As I understood it at the time that the HTML BLINK element was first deprecated, it's because certain blink rates can trigger seizures. I've never heard of a looped animation doing that, unless the animation is essentially two images displayed alternately. --Redrose64 🌹 (talk) 08:20, 27 September 2024 (UTC)

It doesn't only say blinking, it also says moving or scrolling. The area of concern is "The intent of this Success Criterion is to avoid distracting users during their interaction with a Web page." Long form animations need to be done via a pauseable video rather than by an uncontrollable animated GIF. Thisisnotatest (talk) 09:57, 27 September 2024 (UTC)

I'm just trying to fully understand what SC 2.2.2 says and why. Most concretely, it says:

• Content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen readers.
• Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of the Web page.

The first point is about moving content in general, and doesn't really apply to our conversation about looping GIFs in particular. The second specifically discusses blinking content, which is the distinction I'm currently unclear about. Remsense ‥ 论 10:04, 27 September 2024 (UTC)

Do we need to call out team and transit colors under color?

I notice a lot of issues on Wikipedia where text has contrast issues because someone has duplicated team or transit route colors. Do we want to specifically mention that using team and transit colors for text is not exempt from meeting contrast requirements, and that accessibility takes precedence over non-logo branding?

Team example

Geelong West Giants uses white text on a orange background extensively. Orange text or backgrounds are particularly problematic because white on orange fails WCAG 2.x contrast test, but some people find orange on black harder to read. The logo doesn't need to meet contrast, but text does. The best practice would likely be to abandon the orange background.

The color #FFFFFF (white) on #F15C22 (orange) has a contrast of 3.33:1, which fails for text smaller than 18.66px bold or 24px not bold.

Transit example

{{Transport in Mexico City}} themes colors by route and mode. Several of the routes use insufficient contrast, such as Cablebús line 1, which has white on light blue, which violates contrast at all sizes.

The color #FFFFFF (white) on #4EC3E0 (light blue) has a contrast of 2.05:1, which fails for text at all sizes. This issue is complicated that the icon is supplied by the government of Mexico City, but the license permits modification, such as making the "1" black instead of white (changing fill="#FFFFFF" to fill="#000000" in the SVG code). But it might be simpler and less distracting to use actual text rather than an SVG image.

Thisisnotatest (talk) 21:24, 27 September 2024 (UTC)

These colors have always been horrible, and not only for accessibility reasons. Look at Template:Geelong Football League, the hyperlink in title is completely hidden. Gonnym (talk) 21:32, 27 September 2024 (UTC)

Many years ago, the ice hockey WikiProject moved to using colour borders instead of colour backgrounds in order to improve accessibility (including legibility). See Template:Montreal Canadiens for an example. (Some ice hockey editors don't like how it looks, while others do, but the consensus has held.) I feel this approach is a reasonable tradeoff between visual design goals, and should be considered for other similar scenarios. isaacl (talk) 16:22, 28 September 2024 (UTC)