Wikipedia talk:Manual of Style/Accessibility

Skip to table of contents

Please place new discussions at the bottom of the talk page.

This is the talk page for discussing improvements to the Manual of Style/Accessibility page.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Shortcuts

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17: 90 days

Manual of Style

	This page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style articles
	This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
	For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

Accessibility

This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.AccessibilityWikipedia:WikiProject AccessibilityTemplate:WikiProject AccessibilityAccessibility articles

Wikipedia Help B‑class Mid‑importance

	This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp articles
B	This page does not require a rating on the project's quality scale.
Mid	This page has been rated as Mid-importance on the project's importance scale.

Text in images

One thing I can't see covered by the MOS is the matter of text size in images. There has been a trend in recent years for more and more information to be added into maps used in election article infoboxes, such as bar charts, pie charts, legends etc (for example, there is currently a proposal to change the US presidential election map from this (in which the text is legible at the scale it is shown in the infobox) with this (which has text that is completely illegible at the scale shown in the infobox, and some so small it is not even legible when clicking through to the file page and can only be read by opening the image full screen).

Is this an accessibility issue, and if so, should there be a minimum font size requirement for text in images (e.g. that the image is shown at a size where the text appears equivalent to a certain font size)? Cheers, Number 5 7 12:56, 20 March 2024 (UTC)[reply]

Number 57. People need to look at the image at the scale it is shown in the infobox in cell phones too. For example, see this:

Wikipedia talk:WikiProject Maps#Ability to distinguish "D" on map on cell phones

See table: Over 50 percent of website traffic is from cell phones.

--Timeshifter (talk) 04:37, 7 June 2024 (UTC)[reply]

I agree, but is there actually a guideline/policy on this, or a desire for one? Number 5 7 03:02, 8 June 2024 (UTC)[reply]

Number 57. I think we are at the stage of drumming up support. I tried to make the text size as large as possible in the maps in this category:

c:Category:English-language SVG choropleth maps of the United States made with templates

The text could be made larger if 2-letter state abbreviations were used instead of full state names. But most people do not know what all the abbreviations stand for.

As I just noted at the previously-linked talk page:

Wikimedia is rolling out a text sizing menu with 3 choices: small, standard, and large. I have it set on large. So there is a definite desire for more accessibility. Map editors should honor this too. See:

http://eu.wiki.x.io/wiki/Topic:Y5nbfld32in1ud0k

It is a default setting for logged out users. Log out and bypass your cache to see the text-sizing menu. It can be hidden to a link toggle that shows the menu.

Logged in users can enable it via the beta preferences:

Special:Preferences#mw-prefsection-betafeatures - "Accessibility for Reading (Vector 2022)".

So people are waking up to the need to make Wikipedia even more accessible.

--Timeshifter (talk) 12:23, 14 June 2024 (UTC)[reply]

Diff color change on mobile web editor

The mobile web editor used to show added and removed text in red and green respectively, making it clear to 97% of editors what is happening in that diff. These colors have now been changed to blue and yellow, so that no one can tell which text was added vs removed. This change will lead to good edits getting mistakenly reverted and contributors driven away from editing

I'm pretty sure this is a misguided accessibility change but I don't know who is in charge of this feature. (t · c) buidhe 18:58, 21 June 2024 (UTC)[reply]

@Buidhe Hi, this change for the mobile web editor was made in February (in phab:T350181). I believe the best place for feedback would be mw:Talk:Reading/Web/Accessibility for reading, where the relevant team will see it. I hope that helps. Quiddity (WMF) (talk) 21:08, 21 June 2024 (UTC)[reply]

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:

http://en.wiki.x.io/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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]