This module was considered for deletion on 2020 February 15. The result of the discussion was "keep".
Module:Message box is permanently protected from editing because it is a heavily used or highly visible module. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit protected}} to notify an administrator to make the requested edit.
NOTE: The current icons are licensed such that they do not need the link to work so that arribution works. These new icons are CC4 licensed, so attribution would be needed and the link= attribute would also need removing from the code if these are to be used. -- WOSlinker (talk) 12:23, 10 August 2025 (UTC)[reply]
Also some the icons have already been there for a few years, and marked with {{CC-by-4.0}}, mistakenly too I assume. Anyway, I marked my colourings of the icons with that too since it was a derivation.
MOS:PDI says that a blank |link= param - which is what we essentially do with mboxes - should not be used with CC BY-SA, GFDL, or similarly licensed images. I think that I'm right in saying that c:Template:MIT License falls within "similarly licensed images". --Redrose64 ๐น (talk) 13:24, 10 August 2025 (UTC)[reply]
@Redrose64 Where in the quoted policy does WP:PDI state a blank |link= param - which is what we essentially do with mboxes - should not be used with CC BY-SA, GFDL, or similarly licensed images.? I couldn't find it. waddie96 โ (talk)16:25, 10 August 2025 (UTC)[reply]
You should always endeavor to use the default aria role element. In this case, that's not a table. Ignoring that, tables are shit for doing other presentation with. Izno (talk) 03:20, 29 August 2025 (UTC)[reply]
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.
The elements with role=none (synonym for presentation which is not recommended for use) is not be hidden from the accessibility API but their implicit semantics are hidden. Meaning the contents of an Ambox for instance will not have the implicit semantics of a HTML data <table>. So the content given in |text= will simply be presented to the accessibility API technology as <div>Content</div> instead of <table>Content</table> which is what we want, yes. However, the accessibility technology, i.e. screen reader, etc., will not have any idea what this text is or what it represents since the <div> element that it 'sees' has no implicit role, such as with <p>Content</p> for instance, and there is no aria-label given... 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.
I interpret this as meaning that the <img> element inside the first <td> element will be exposed, and it is simply an image/icon with no benefit to the screen reader or the visually impaired... so give the image <td> element with class mbox-image the HTML attribute: aria-hidden="true"; so that it is completely hidden from the accessibility technology.
The 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 does not fit any other ARIA role, and the child elements of that will all be exposed to the API as whatever has placed in the text parameter anyway (as confirmed in the quote above). Finally I suggest giving it an aria-label="Notice" if |type=notice or style or content, and possibly aria-label="Warning" if delete or speedy. So it'll read out with a screen reader for example as: Note. Notice. Content...
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 giving it an aria-label="Notice", 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.
How about we wait to suss out how we want to deal with any accessibility questions here after I've got everything in divs, as in the section just above. Anyway, I think the last time I looked at this, the most similar was role=note for what message boxes represent. I am pretty sure I am not a fan of adding labels here, which should be when the content needs naming, and this does not. Izno (talk) 03:24, 29 August 2025 (UTC)[reply]
Cool. Please do ping me in discussions when this is revived. I've read extensively for many hours for something else and I'm quite well versed in it now. Yes, role="note" is the most appropriate role. Also, after testing it in the enwiki context using a few different screenreaders I tend to agree with you that an aria-label in this case is unnecessary "fluff" to the accessibility tree for the mbox, since as you stated the text describes itself. ๐ waddie96 โ (talk)14:56, 29 August 2025 (UTC)[reply]
The discussion above 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.
Wow, thought I'd summarise:
Change the ARIA role given to the parent <table> element to role=none. Synonymous to presentation, i.e. identical function of removing all semantic meaning of table element and its direct children, but the latter is soon-to-be deprecated HTML.
Hide the images please: wrap the default image, and especially the custom left and right images (since the default at least has a null |alt=) with <spanaria-hidden="true">...</span>.
I think Izno suggested waiting until the div conversion was done, and then looking to see if anything like this is needed? โ Martin (MSGJ ยท talk) 14:33, 4 September 2025 (UTC)[reply]