Module talk:Message box

Module talk:Message box

Please use this talk page to propose and request changes to the Module:Message box or any of its subpages. Use {{editprotected}} so your request can be noticed. If your request is not handled for some days you may leave a message in the administrators' noticeboard. Thank you.

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. For the archive overview, see Module talk:Message box/Archives. The latest archive is located at 2026.

Protected edit request on 5 July 2024

Please sync the styles again so dark mode is supported. Sjoerd de Bruin (talk) 16:05, 5 July 2024 (UTC)

Sync what page to Module:Message box/ombox.css? — xaosflux ^Talk 15:22, 8 July 2024 (UTC)

I'll propose these fixes, instead of Sjoerddebruin's ambiguous request!

• Add this string, underneath the specified line, within the following pages:

color: #222; /* temp fix for dark mode */

• under line 7, at Module:Message box/cmbox.css
• under line 8, at Module:Message_box/fmbox.css
• under line 7, at Module:Message_box/imbox.css
• under line 12, at Module:Message_box/ombox.css
• under line 7, at Module:Message_box/tmbox.css

(Note: I've tested these at Mediawiki-wiki, and I asked for dev-confirmation that it's ok (they said yes)). Much thanks! Quiddity (talk) 00:17, 9 July 2024 (UTC)

Done that. * Pppery * _{it has begun} 00:12, 11 July 2024 (UTC)

Edit request for dark mode compatibility

Please Special:Import the following pages from enwiki to get dark mode fixes:

• Module:Message box/cmbox.css
• Module:Message_box/fmbox.css
• Module:Message_box/imbox.css
• Module:Message_box/ombox.css
• Module:Message_box/tmbox.css

Thanks, —Matrix (_{user page} ^{(@ commons)} - _talk?) 09:01, 26 August 2024 (UTC)

Done. I didn't actually use Special:Import since that does undesirable things to the page history. I copy-pasted instead. * Pppery * _{it has begun} 21:52, 28 August 2024 (UTC)

@Pppery: just realised, you forgot cmbox —Matrix (_{user page} ^{(@ commons)} - _talk?) 20:04, 5 September 2025 (UTC)

Done. * Pppery * _{it has begun} 20:06, 5 September 2025 (UTC)

Edit protected 2025-08-23

Good day. Can we change the role= attribute of boxTable from presentation to none per w3c.github.io/aria/#presentation. With none it means (per prev. quoted W3C doc):

The intended use is when an element is used to change the look of the page but does not have all the functional, interactive, or structural relevance implied by the element type, [...] Example use cases: A layout table and/or any of its associated rows, cells, etc.

However, we do not define role= again so all the children of the table element that holds the mbox, ambox, etc class for messageboxes get the role=presentation which is a synonym for none, and if you Inspect element on template:ambox for example the element containing the ambox class (which is a table yes) will be hidden from the accessibility API.

I suggest we remove giving the table element any role (as from what the W3C doc states it seems the children will all be forced to inherit this role even if we define it), and instead give the mbox-text class the role=note as its contents is what needs to be exposed to the accessibility API, and the other children (I believe there's only one) mbox-image the role=none. Per the W3C doc w3c.github.io/aria/#note:

A section whose content represents additional information or parenthetical context to the primary content it supplements [...] A note is content provided by the author of the page or document [...] When used within the normal flow of a page's content, a note has an implicit association with the content that it supplements.

It must have been implemented and just stayed there after this discussion.

To be honest, I know little about W3C and accessibility I'm just someone trying to meet the 2.0 standard in some way as I go along editing other stuff. So it might be helpful to get an opinion from someone at WMF or a fellow contributor who knows something about this.

I'll try drop an invite pointing to the discussion on the w:MOS:ACCESS talk page, at WikiProject Accessibility, and maybe ask a well-versed developer from the Phab Accessibility tag workspace to chime in? Waddie96 (talk) 09:22, 23 August 2025 (UTC)

Correction: The elements with role=none will not be hidden from accessibility API but their implicit semantics will be hidden. Meaning the contents of an ambox for instance will not have the implicit semantics of a data <table>. So the content set in |text= will simply be presented to the API as ‎<div>Content‎</div> instead of ‎<table>Content‎</table> which is better, yes. However, the accessibility technology, i.e. screen reader, will not have any idea what this text is or what it represents since the div element has no aria-label or implicit role such as with ‎<p>Content‎</p> for instance... So I suggest we give it these values especially since:

If presentation or none is applied to a <table> element, the descendant <caption>, <thead>, <tbody>, <tfoot>, <tr>, <th>, and <td> elements inherit the role and are thus not exposed to assistive technologies.But, elements inside of the <th> and <td> elements, including nested tables, are exposed to assistive technologies. — taken from [1].

This means that the ‎<img> element inside the first ‎<td> element will be exposed, and it is simply an icon with no need to be screen read... so give the image ‎<td> element with class mbox-image the HTML: aria-hidden="true"; so that it is completely hidden from the accessibility technology.

Next ‎<td> nests our mbox-text class with the actual stuff we want to expose. But we want to give it meaning too. The role should be: role="note" as it's a note semantically speaking, and the child elements of that will all be exposed of whatever the user has placed in the text parameter anyway. Finally give it an aria-label="Notice text" if |type=notice or style or content, and aria-label="Warning text" if delete or speedy.

:Option 2... the parent element may actually be what we need to expose because it's nesting the whole dang thing? I don't think it matters since the parent elements of the text element are hidden from the API but another solution possibility could be setting the entire ‎<table>'s role to role="note", and then still hiding the image, and then leaving the text element alone, however I'm unsure if the note role is inherited by child elements like the none/presentation role is.Waddie96 (talk) 23:22, 28 August 2025 (UTC) (edited Waddie96 (talk) 15:18, 29 August 2025 (UTC))

@Waddie96: Which other projects have already made this accessibility change? Have you tried it in a sandbox and tested it with a screen reader? If not, please test your changes in a sandbox first before proposing them here. – DreamRimmer ■ 15:42, 29 September 2025 (UTC)

Yes, I use a screen reader. At enwiki and commons Waddie96 (talk) 15:44, 29 September 2025 (UTC)

Please prepare your version at Module:Message box/sandbox, and if everything works as intended, I will replace the current module with the updated version. Also, please share links to the modules from other wikis where this has already been implemented. – DreamRimmer ■ 15:52, 29 September 2025 (UTC)

@Waddie96: Any update? – DreamRimmer ■ 11:25, 3 October 2025 (UTC)

Oh completely detracted by another project. I'll do this now and ping when done :) Waddie96 (talk) 22:03, 3 October 2025 (UTC)