Shortcuts

SANDWICH Issue

Latest comment: 8 months ago15 comments5 people in discussion

The WKEY (AM) article has been identified as having SANDWICH issues. Previously the two images in the article were placed in the two sections within the article and for 10 years has never raised an issue. I should note, this is a Good Article, so it's been through scrutinized over and no accessibility issues were raised during it's GAN.

An editor (BlueboyLINY) who works with your project, moved them below the infobox. Since this is a Good Article, this is not preferable. Typically, images are preferred in line of the sections that describe the image. Since this is a small article, it only has two sections where text is and those are in-line with the infobox.

Working to find a solution, he suggested the images be placed in a gallery. Keeping in line with the Good Article standards, I moved them to a gallery in the previous position. While, admittedly, not perfect, the images were smaller than previous. The editor's idea was to center them under a line of text. This isn't doable and frankly looks silly. I reverted to the previous temporarily while I bring it to you all for your advice and input. - Neutralhomer • Talk • 02:56, 28 January 2026 (UTC)Reply

I have cross-posted this discussion to the GAN talk page and the WP:WPRS talk page for their input as well. - Neutralhomer • Talk • 03:16, 28 January 2026 (UTC)Reply
While I agree that this is a problem with the image placement in this article, I am not convinced it is a GA problem. The GA criteria only cover a subset of the MOS and content guidelines and I don't see MOS:IMG among them. —David Eppstein (talk) 07:37, 28 January 2026 (UTC)Reply
I don't see how this has much to do with it being a GA or not. Lee Vilenski (talk • contribs) 09:18, 28 January 2026 (UTC)Reply
@David Eppstein and Lee Vilenski: Thanks for your input. We can scratch off GA as an issue and just work on a visually better solution. Thanks again! - Neutralhomer • Talk • 16:46, 28 January 2026 (UTC)Reply
Personally, I think most of the issue is that the infobox is MASSIVE. Why does it have so much information in it? Lee Vilenski (talk • contribs) 18:46, 28 January 2026 (UTC)Reply
@Lee Vilenski: That's actually pretty standard for a WP:WPRS infobox. There are some, like WINS-FM, that are considerably longer. Though, some of that information can go away, since the station is no longer on the air. Let me see what I can do to trim it. It won't be much, though. - Neutralhomer • Talk • 22:15, 28 January 2026 (UTC)Reply
I didn't think I'd be able to trim much from the infobox, but I tried. - Neutralhomer • Talk • 22:20, 28 January 2026 (UTC)Reply
Maybe that's an issue then. Infoboxes really aren't supposed to take up a whole page of screen size or have to scroll to see it all. Lee Vilenski (talk • contribs) 22:33, 28 January 2026 (UTC)Reply
Everything in that infobox looks appropriate for infoboxes. The only thing I'd consider removing is the list of links, and that's a general grief not just to this page, not just to the infobox template, but all infoboxes. Izno (talk) 23:44, 28 January 2026 (UTC)Reply
@Lee Vilenski: That would be a much larger conversation, to be honest. There are approximately 20,000 articles within WP:WPRS and all have infoboxes and all are jam packed. Some are admittedly smaller, but all have the basic information. That's not something I, personally, can do much about, unfortunately.
@Izno: You mean the website and webstream links? I could remove those. See, the station itself is off the air, but the station's programming got moved to an HD2 stream of an FM station. So, technically, the links are still valid and working (the livestream is still working), it's just now on a different frequency. I know, confusing. :) - Neutralhomer • Talk • 02:04, 29 January 2026 (UTC)Reply
I'm of the general opinion that it's self defeating to put any URL in the infobox as a main entry (see also WP:EL regarding links in the content instead of in specified regions). This is non-specific to this case but those are things that could be removed at the template's level here that would help trivially across all radio station articles. Izno (talk) 02:07, 29 January 2026 (UTC)Reply
I will start with this one, ping @Sammi Brie:, who kinda "runs" WPRS, for the rest of the articles (again, I only have very limited control). - Neutralhomer • Talk • 02:12, 29 January 2026 (UTC)Reply
This is more a question of the size of {{Infobox radio station}}, which has a lot of technical information that lives there and not in many other places, a la {{chembox}} or similar.
Some comments on the instant case:
  • I'd have removed the website and webcast links in this instance, even though they continue to exist as part of the fact that an HD2 is now feeding the translator. I don't think anything else begs removal.
  • I think the linking discussion is honestly at a higher level than this one, probably even at RfC.
There really are no good solutions on the sandwich front. Sammi Brie (she/her · t · c) 07:05, 29 January 2026 (UTC)Reply

@Sammi Brie: Thanks for your work on the page. I didn't think there were any good options on the sandwich front, unfortunately. Someone is gonna be unhappy no matter what we decide. Should we just return it to how it was and call it a day? - Neutralhomer • Talk • 23:53, 29 January 2026 (UTC)Reply

Blind People

Latest comment: 8 months ago1 comment1 person in discussion

--Guy Macon (talk) 05:00, 3 February 2026 (UTC)Reply

Tower of London article

Latest comment: 7 months ago2 comments2 people in discussion

Good evening, I tried (unsuccessfully) to add some breaks to long blocks of text on the Tower of London article today. I was swiftly reverted. Then I went over the edit history of the page and saw that attempts to make the page more user friendly are typically reverted pretty quickly. I won't attempt to edit the page again, but I did leave a message on the talk page outlining my concerns. If someone in this group has time to check it over in light of MOS:ACCESS and WCAG, I leave it in your more capable hands. FallingRocksAhead (talk) 05:21, 8 February 2026 (UTC)Reply

@FallingRocksAhead: Answered there. --Redrose64 🌹 (talk) 20:29, 8 February 2026 (UTC)Reply

Alt text guidance?

Latest comment: 6 months ago1 comment1 person in discussion

There is a discussion at Wikipedia talk:Featured article candidates#Is 2019 RfC still valid? Alt text is not required in FA articles? about how WP:FAC should deal with alt text. The gist is "We generally think it's a good idea but don't know how to write good ones so we've shied away from requiring it". If anybody could provide some useful input, please join the discussion. RoySmith (talk) 20:13, 5 April 2026 (UTC)Reply

Discussion at WP:AINB § Wendy at AgenticCommons

Latest comment: 4 months ago1 comment1 person in discussion

 You are invited to join the discussion at WP:AINB § Wendy at AgenticCommons. Kowal2701 (talk, contribs) 18:08, 26 May 2026 (UTC)Reply

Discussion at User talk:Sammi Brie § User:BlueboyLINY

Latest comment: 2 months ago1 comment1 person in discussion

 You are invited to join the discussion at User talk:Sammi Brie § User:BlueboyLINY. Sammi Brie (she/her · t · c) 05:27, 16 July 2026 (UTC)Reply

Should portal icons obey MOS:BLANKALT ?

Latest comment: 1 month ago11 comments6 people in discussion

From a discussion started at Template talk:Portal:

A large number of PD portal icons use link=|alt=flag or similar, e.g.:

I see that MOS:BLANKALT directs us to use link=|alt= for purely decorative images. Are portal icons purely decorative? Should we blank the alt field from PD portal icons? Guidance from users who have experience with screen readers is very welcome.

Coeur has a proposal for adding alt=icon to portal icons which currently have empty alt. I'll let them explain the reasoning behind their proposal. — hike395 (talk) 16:36, 6 August 2026 (UTC)Reply

Pinging @Waddie96 who had asked about this a few months ago. — hike395 (talk) 16:56, 6 August 2026 (UTC)Reply

Pinging @Trialpears, Graham87, TheDJ, Bpmcneilly who participated in a discussion related to this last September. — hike395 (talk) 17:16, 6 August 2026 (UTC)Reply

Yes, these are purely decorative. Izno (talk) 17:22, 6 August 2026 (UTC)Reply
probably? We are not really trying to communicate the icon/flag design to people. We are providing a visual recognizable “mental quicklink” for people to not have to read the link text. —TheDJ (talk • contribs) 19:39, 6 August 2026 (UTC)Reply
If the icon is CC0 or public domain (or licensed with certain uncommon licenses like WTFPL), I'd say they're purely decorative and link=|alt= would be appropriate. Note, however, that most common licenses, such as GFDL, CC BY, and CC BY-SA, require that we provide attribution and a notice that the image is under the particular licenses, which we usually satisfy by linking the image to the file description page where this information is present. In these cases, link= should not be used, as described in more detail at MOS:BLANKALT and MOS:EMPTYALT, and an alt= such as alt=flag or alt=icon would be appropriate.
As for Coeur's claim that Slack or Google tend to pick the first image of the page with alt="", I'd question that. More likey, as I understand it, is that they'd pick up the image specified by the OpenGraph metadata provided by mw:Extension:PageImages. Anomie⚔ 20:24, 6 August 2026 (UTC)Reply
as a screen reader user I'd slightly prefer them to obey the Manual of Style (i.e. have blank alt text when possible) but it's not that big a deal for me either way. Graham87 (talk) 06:34, 7 August 2026 (UTC)Reply
See here, the "2000s Portal" image was the first image of the page with an empty `alt=`, and so it got picked by Slack. To avoid that, we'd want an `alt=icon` for all the ignorable images. Coeur (talk) 12:28, 7 August 2026 (UTC)Reply
No we should never be tailoring wikitext to implementations of specific apps. It's too fragile. If slack doesn't listen to the opengraph metadata, that's their problem and we should make a bug report with Slack. We should always follow the best HTML and accessibility conventions. They are the most durable way forward. —TheDJ (talk • contribs) 13:23, 7 August 2026 (UTC)Reply
Looking at the current version of Halloween (franchise), it seems the page has no page image at all, which might help explain why Slack fell back to some other image. OTOH, when I check the page I find that the "2000s Portal" image is actually the last, not the first, of six with no alt. Or Slack may be doing something else entirely to choose the image in the absence of OpenGraph metadata, as "pick an image with no alt" seems an odd criterion for it to use in the first place. Anomie⚔ 14:44, 7 August 2026 (UTC)Reply

Should I blank the alt field for all unlinked portal images? It sounds like that is the consensus, but I want to make sure before doing something that affects hundreds of thousands of pages. — hike395 (talk) 02:11, 29 August 2026 (UTC)Reply

Discussion at Template talk:Val § Screen readers

Latest comment: 1 month ago1 comment1 person in discussion

 You are invited to join the discussion at Template talk:Val § Screen readers. Lugel (talk) 11:33, 17 August 2026 (UTC)Reply

Clarification on what are decorative images

Latest comment: 1 month ago2 comments2 people in discussion

what counts as a purely "decorative image" on Wikipedia? as its definition seems to be stricter than other internet guidelines. noting this after a discussion about implementing policies for requiring alt text on English Wiktionary, some editors argue that in a dictionary entry, say, an image for a dog on the entry for "dog" would be purely decorative as these serve only those that are sighted and willing to look at the images and are not essential information to understand the information of the entry. because of that, I would like to understand better the position of the workgroup. hope this is not drifting too off-topic. Juwan 🕊️🌈 19:31, 2 September 2026 (UTC)Reply

Basically, can the article be understood to the same degree if the image concerned is removed entirely? If it can, the image is decorative. --Redrose64 🌹 (talk) 06:03, 3 September 2026 (UTC)Reply

Discussion at Wikipedia talk:Manual of Style/Accessibility/Alternative text for images § Straw poll on the quality of MOS:ALT

Latest comment: 17 days ago1 comment1 person in discussion

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Accessibility/Alternative text for images § Straw poll on the quality of MOS:ALT. Guy Macon (talk) 22:05, 18 September 2026 (UTC)Reply

Brainstorming for a Wikipedia accessibility policy

Latest comment: 1 hour ago5 comments3 people in discussion

Wikipedia:Manual of Style/Accessibility (MOS:ACCESS) is a guideline describing techniques to achieve accessibility on Wikipedia. However, Wikipedia does not yet have an accessibility policy. The concept of an accessibility policy has been discussed previously here a few times. There was a prior proposal to incorporate accessibility, by way of nondiscrimination, into the Wikipedia:Five pillars, that was unsuccessful. I haven't, however, seen a prior attempt to draft an accessibility policy.

A frequent issue I've encountered, and I'm sure many have, in implementing accessible solutions in Wikipedia content is that MOS:ACCESS is a style guideline, which limits the authority one can call upon to persuade others that accessibility should trump things like decorative preferences. An accessibility policy would fill the gap remaining after MOS:ACCESS by (1) setting forth the very persuasive normative rationale for an accessible Wikipedia, which we haven't effectively done before, (2) committing Wikipedia to accessibility standards, and (3) giving authority to the primacy of accessibility over objections solely based on aesthetic concerns.

I've started a draft, although I've labeled it a brainstorm because I want to emphasize my openness to hearing what we all think such a policy should say and do. It's at User:Bsherr/sandbox2. I'd like to eventually place it over the redirect at Wikipedia:Accessibility. I would like to work toward making it a draft we can present at the pump, and then hopefully a proposal. Please take a look and feel free to make direct edits to it or to leave comments, preferably right here. Bsherr (talk) 23:29, 5 October 2026 (UTC)Reply

The reason it is under the MOS is that it was moved there without reason approximately a decade ago. There's no reason it needs (or should) to live there. Izno (talk) 01:57, 6 October 2026 (UTC)Reply
I think MOS:ACCESS was always tagged as a guideline within the Manual of Style, and that the move was part of a renaming of all Manual of Style pages. Am I mistaken about that? Bsherr (talk) 03:47, 6 October 2026 (UTC)Reply
That's pretty much correct. See Wikipedia talk:Manual of Style/Accessibility/Archive 11 § MoS naming style and Wikipedia talk:Manual of Style/Accessibility/Archive 5 § Style cat. As for a proposed policy, I'm honestly not sure that it's worth the trouble and I'm not really up for it. There's a reasonability test and some people with disabilities are really not using the best assistive technology for their situation, either because of economic reasons or a lack of knowledge. For example, the amount of work needed to implement Wikipedia talk:Manual of Style/Dates and numbers/Archive 163 § MOS:NUMERAL and screen readers fully would be absolutely ruinous, for very little benefit. There'd also be the matter with what to do with the Wikipedia:Accessibility and WP:ACCESS links, which are used quite widely. Also see some very early advocacy to make this page a policy archived at Wikipedia talk:WikiProject Accessibility/Archive 1 § Changing a guideline to a policy. Having said all that, I added a note at Wikipedia talk:Manual of Style/Accessibility § Pointer to discussion about brainstorming for a Wikipedia accessibility policy. Graham87 (talk) 04:42, 6 October 2026 (UTC)Reply
I read the thread you linked. It looks like someone was under the mistaken belief that we had to spell out all numbers because screen readers didn’t read them correctly. But then someone tested three screen readers and found this to be false.
I would add that nothing in WCAG requires any alteration to numbers.
Perhaps this brings up something that ought to be included, which is that accessibility does not mean doing anything anyone claims they need, but only what is required by the accessibility standards. Bsherr (talk) 11:32, 6 October 2026 (UTC)Reply