Wikipedia talk:Manual of Style/Accessibility/Archive 14

Archive 10

←

Archive 12

Archive 13

Archive 14

Archive 15

Archive 16

Archive 17

PSEUDOHEAD and definition list

I would like to seek clarification in the guideline related to WP:PSEUDOHEAD in relation to definition lists, particularly when it is defining a list. I'm thinking that we should state at what level PSEUDOHEAD applies and be sure to point to definition list as well. It's not clear and @Izno: pointed out the conflict. There was also a discussion at Talk:Glossary of video game terms#RfC: Replacing pseudo-headers. Walter Görlitz (talk) 05:07, 22 March 2017 (UTC)

"This is a definition list" No its not... That glossary is indeed using pseudo headers. See H:DL for how to make a definition/description list using wikicode. And a description list is indeed proper markup, does not qualify as a pseudohead (because just like headers, a definition list [if using both the term (;) and description-part (:) of it] has semantics, whereas bold tags are purely visual and do not have semantics. —TheDJ (talk • contribs) 06:54, 22 March 2017 (UTC)

Text amended to avoid potential misinterpretation. —TheDJ (talk • contribs) 07:03, 22 March 2017 (UTC)

@TheDJ: That's because of an edit post-RFC which now incorrectly uses bold rather than definition lists. The glossary should be fixed. @Jennica: for courtesy. --Izno (talk) 11:03, 22 March 2017 (UTC)

@TheDJ: It would help greatly if when quoting something that is not stated in the current thread that you would provide attribution (user name, or date and time). It so happens that the only instance of "this is a definition list" that I can find is in my comment of 11:19, 27 April 2016 (UTC) in Talk:Glossary of video game terms#RfC: Replacing pseudo-headers. At the time that I made that post, the article looked like this: it used a semicolon (which emits a <dt>...</dt> element) to name each term, and a colon (which emits a <dd>...</dd> element) to define that term. The dt and dd elements are enclosed in a <dl>...</dl> element. This is the most fundamental form of a definition list. --Redrose64 🌹 (talk) 11:51, 22 March 2017 (UTC)

And I've now fixed the glossary. --Izno (talk) 11:57, 22 March 2017 (UTC)

Example

The list format is applied here. Which is correct in this instance, the list format or the bold? The list elements use bullets. The old format was applied, likely by me, based om PSEUDOHEAD and the new one is more common in band articles. Walter Görlitz (talk) 01:41, 23 March 2017 (UTC)

@Walter Görlitz: it is clear to me that R2me2 (talk · contribs) has gone against WP:PSEUDOHEAD in that edit. --Redrose64 🌹 (talk) 10:57, 23 March 2017 (UTC)

@Walter Görlitz: Neither the list format nor the bold is correct. Those are crystal-clear WP:headings and should be marked up as such with ===. There's absolutely no reason not to make them headings – it improves accessibility all round. --RexxS (talk) 14:03, 23 March 2017 (UTC)

But this creates short sections, and that should not be done. Walter Görlitz (talk) 14:18, 23 March 2017 (UTC)

Of course it should be done. There is no prohibition on short sections, and absolutely no reason to use pseudoheadings when they can be marked up as headings. You know very well that a screen reader can jump directly to a section with a header, but would have to listen to the entire 'Members' section without that markup. We have semantics for a reason, and your insistence on marking sub-headings simply as bold makes the article less accessible. It's quite clear that MOS:PSEUDOHEAD favours the previous version over yours and you should revert your last edit before somebody takes you to task for making articles worse instead of improving them. --RexxS (talk) 14:56, 23 March 2017 (UTC)

MOS:BODY "Very short or very long sections and subsections in an article look cluttered and inhibit the flow of the prose." Granted this isn't prose, so it's even a worse problem. It's not about accessibility here as the reader will simply announce the words rather than state "heading" and then the heading name. No reverting as it's standard practice in the music project now as well, but feel free to do your worst as short sections should be avoided. Walter Görlitz (talk) 15:05, 23 March 2017 (UTC)

There is no way that any reader would find that the headings in this version make the "article look cluttered and inhibit the flow of the prose", any more than your preferred version because they are visually near identical. So your appeal to MOS:BODY makes no sense. On the other hand, MOS:PSEUDOHEAD tells you to "try to avoid using bold markup" for a good reason: the ability of a screen reader to hear all of the section titles and then jump directly to one that they want is valuable to the visually impaired. I'm not going to play games with edit-warriors like you: you know very well that the semantically correct headings improve the article over your bolding, but choose to make articles worse instead of better, for no good reason beyond your personal preference. The fact that standard practice in music articles contains poor practice does not justify it; if anything it's more of a reason to insist on proper markup because not all music articles have such short sections and they are even more in need of screen-reader friendly markup. --RexxS (talk) 15:43, 23 March 2017 (UTC)

Not all music articles do have short sections though, but they are more prone to it. And I'm not playing games, nor am I an edit warrior. Walter Görlitz (talk) 19:41, 23 March 2017 (UTC)

The conflict with MOS:BODY comes from the fact that we prefer our articles to be well proportioned contextualised, FA-quality prose, which conflicts with non-ideal 'works in progress' on an issue like accessibility. However, I note that problems like these will always have grey areas of course, and there is no reason to escalate issues like this in revert wars etc.. For example:

1. Let's go with the original of bold+unordered list
   • The user would hear approximately "Heading level 2. Members, Current, list [4 of 4], text 1 of 4, link, name, ... end of list" Former, list" etc..
   • While perhaps not perfect that should definitely be understandable
   • The bold gives visual emphasis on 'Current', but for a screenreader, it's probably perfectly fine to not even have emphasis whatsoever. You might even call the bolding 'decorative'.
   • It could be considered to replace bolding with the usage of the strong tag, so that a screenreader might also be able to express the emphasis.
   • It could also be considered to have a plain : after the word Current, to improve the pronunciation of the sentence.
   • It could be considered to just remove the bolding and turn this into a paragraph: "The current members of the band since 20... are: list".
   • Overall however, the form it is not prohibitive in communicating the information to both audiences.
   • This is why the guideline says "try to avoid bold" and "where TOC limit cannot be used [..] using bold for headings causes the least annoyance for screen reader users". You could replace that line with "in non perfect works, non perfect solutions that don't cause hinderance can be used".
2. A descriptive list
   • It could be argued that having this as an unorderlist inside a descriptive list, would actually fall within the definition of a descriptive list as defined in HTML5 (where it also allows for Q&A layout for instance).
   • However, screenreaders do not yet reflect this new definition very well, so I would not choose it.
   • Note that if this solution were to be used, you do have to prefix the unordered list with : which the original example did not do.
   • Because no matter what, the usage of ; if it is not followed by : is ALWAYS WRONG and even more wrong than using bold to create a visual header.
3. Headers
   • The user will approximately hear: "Heading level 2. Members, Heading level 3, Current, list [4 of 4], text 1 of 4, link, name, ... end of list, Heading level 3, Former, list" etc..
   • Will definitely work very well for screenreaders.
   • Almost the same visual style as originally desired
   • Included in Table of Content navigation for screenreaders to quickly jump between sections, and to give overall overview of the article
   • It's a very short section, so it can be argued that even for screenreaders there is little additional value in having 4 headers, for a piece of content that is as short as it is. It could even be argued that this would be annoying for screenreader users to have multiple header interruptions in the prose.

I would personally use either solution 1, with the described improvements for the current prose situation, but preferably solution 3 and just improve the prose to no longer make the downside of that solution an actual problem. As stated earlier, for a messy situation like an imperfect and short article both solutions have downsides and as long as that is not prohibitive towards the ability of people to consume the right information, then it is probably not something to argue about. Most important is to not have a broken situation, like introduced here. —TheDJ (talk • contribs) 18:02, 23 March 2017 (UTC)

Thanks for the detailed explanation. There's nothing preventing the use of semi-colons to format "current", etc. and colons for the entries. We could request that music project go with that. What works best overall? Walter Görlitz (talk) 19:41, 23 March 2017 (UTC)

I just want to know what to use next. I was reverted on Rufus Wainwright after changing the semicolons to bold markup under Discography and Tours and now I am seeing the best option is to make them level 3 subheaders? Please ping me with what I should be using now. Not like semicolons are already so ingrained in people's formatting anyway... --Jennica✿ / ^talk 20:15, 23 March 2017 (UTC)

I tried to follow this as the other editor involved on Rufus Wainwright. MOS:BOLD doesn't appear to make allowances for boldfacing in this type of scenario and doesn't even mention accessibility concerns, unless I misread it. The way I'm reading this discussion is that semicolons would also be considered preferable to boldfacing. Thank you for clarifying. DonIago (talk) 20:20, 23 March 2017 (UTC)

It's my understanding that semicolons would be fine, but without bullets. Walter Görlitz (talk) 20:29, 23 March 2017 (UTC)

Semicolons have always been frowned upon, was my understanding. It was previously discussed here --Jennica✿ / ^talk 20:50, 23 March 2017 (UTC)

I'll reiterate what everyone should be taking from the above discussion: An actual header (at the correct level) is ideal. A semicolon that is NOT PAIRED WITH a colon (;pseudoheader) is WRONG. It's is HALF of a descriptive list item and thus a BROKEN list. Contrasted with a proper descriptive list (; term : definition). A descriptive list isn't currently a good match for a header+list. The pseudoheader form of using boldface, while possible in some cases, is to be avoided when possible.

The ask of the project here seems to be "Give us wikicode syntax that is applicable to all our and reader's situations". The answer is "That wikicode might not exist". Be flexible, or write more prose and fewer lists that require names in order to detail what they are about, to avoid the entire problem. —TheDJ (talk • contribs) 20:51, 23 March 2017 (UTC)

@TheDJ: The last part doesn't apply to me. I don't write prose. I work mainly on album articles that have Personnel sections and in that link I posted above, SilkTork said semicolons should basically be the last option. The problem is is that there's no consensus and now I'm confused on what to use. A few months back, I was told by another user not to use the semicolons as bold markup. Now I'm being told to do so? --Jennica✿ / ^talk 20:58, 23 March 2017 (UTC)

@TheDJ: But a heading makes short sections and that's not ideal either. Walter Görlitz (talk) 21:05, 23 March 2017 (UTC)

Exactly. Like I said, there is no answer towards that problem. You have to choose either accessibility (headers), or less-accessibility (bold pseudo headers). Or change the writing style. —TheDJ (talk • contribs) 21:07, 23 March 2017 (UTC)

@Walter Görlitz: As a rule, we should prioritize the important issues of accessibility and proper semantics over the minor concern of short sections. Where short sections would occur, there are usually ways to restructure to avoid them, too. {{Nihiltres |talk |edits}} 23:19, 23 March 2017 (UTC)

It appears, as shown above, it's worse with short sections in almost every respect. Both for accessibility concerns and people with taste in design. Walter Görlitz (talk) 23:25, 23 March 2017 (UTC)

It's really not difficult:

• Using semicolon markup for these sort of lists of members is wrong. They are not description lists and the markup used produces broken html, which is a real problem for screen readers.
• Where there are headers, use header markup. Here's a scenario you haven't considered: If a JAWS user revisits the page of a band trying to remember who was in "Former members" they can get a list of all headings with Insert + F6 or simply step through the headings with H until they find the "Former" heading. Contrast that with having to go to a "Members" heading and reading through all of the lists, some of which might be quite lengthy in some articles. The advantage of quick navigation more than outweighs any annoyance at repetition of the word "heading".

Using bolding to indicate a heading is a poor idea. It is less annoying than a broken description list, but offers none of the advantages of using sub-headings. Why do you think we have sub-headings if you are going to reject their use in precisely the places where they are appropriate. The question you haven't answered is why do you think heading markup makes a short section, when the bold markup doesn't? Visually they are the same, and the issue of small sections containing lists that break up the article's prose and appearance is an issue of content, not markup. From the reader's point-of-view, they see short sections whether bold or heading markup is used. So you're wrong on both counts: from an accessibility perspective, the heading is better than the bold always; from a "taste in design" perspective they are equivalent. There's simply no scenario where bold markup has any advantage over headings.--RexxS (talk) 01:33, 24 March 2017 (UTC)

It's really not difficult: you're not listening. Using bold is not a poor idea and it was actually suggested that it might be better above. Semicolons could be used if the lists were changed into colons lists rather than bullets. I like the idea of using prose below as well, but short sections can easily be avoided and accessibility guidelines can be honoured. Walter Görlitz (talk) 05:31, 24 March 2017 (UTC)

Actually, you haven't taken in anything that's been explained to you. Bolding to create pseudo-headings is, and always has been, a poor idea. (1) See MOS:BOLD and try to understand that marking up headings is NOT a use for bold text. (2) If a heading isn't marked up as a heading, screen readers can't use them for navigation. I also like the idea of a prose introduction to a list, but that is still no reason not to mark headings as headings for the benefit of the visually impaired. Do you have any answer to those two points? No? I thought not. --RexxS (talk) 18:55, 25 March 2017 (UTC)

Alternate writing style

====Members====

The current members of the band are:

• Shane Blay – lead vocals, rhythm guitar (2013–present)
• Nick Hipa – lead guitar (2013–present)
• Josh Gilbert – bass guitar, vocals (2013–present)
• Jordan Mancino – drums (2013–present)

In the past the band has also featured:

• Phil Sgrosso – rhythm guitar, programming (2013–2016)

References

That could be done as well. If we draft a section for the music MoS, would you be able to review the suggestions? Walter Görlitz (talk) 21:57, 23 March 2017 (UTC)

This is how I have been doing it since we agreed that solution in November last year. We don't want a header: that has too many issues, it's visually crude, giving an amateurish, gawky, and inappropriate impression to readers; it's intrusive, inhibiting reading flow; gives undue weight to minor matters; and it is the equivalent of SHOUTING in a forum discussion. The def list (semi colon mark up) gives readers using machines a problem. So using an indented or bullet list after an introductory paragraph (which may consist simply of part of a sentence, as in the examples above) seems the most elegant solution. As this is the second time the same solution has come up in relation to this issue, I think it should be discussed with other music article editors, and then written into a guideline. SilkTork ^{✔Tea time} 00:32, 24 March 2017 (UTC)

So TheDJ, this is how it's going to be now? I find this really unfortunate. They were originally semicolons, which I normally would have gone and bolded them but instead made them into level 3 headers. This changes the entire system of wikipedia. So many pages are going to need changing. --Jennica✿ / ^talk 04:36, 24 March 2017 (UTC)

@SilkTork: Headings are used throughout Wikipedia to mark up the title of a section. That is their purpose. Their appearance has a current consensus for how they are presented and if you personally don't like how they display, either alter it in your Special:Mypage/common.css to something less "visually crude, amateurish, gawky and inappropriate", or make the case for a change at MediaWiki talk:Common.css so that we can all benefit from your visually sophisticated, professional, graceful and appropriate suggestion. Of course introductory prose is a good idea for any sub-section, but the case remains for having a sub-section header, if only to save the visually impaired from having to listen to an entire section when they could just jump to the sub-section that interests them.

@Jennica: No it doesn't change "the entire system of wikipedia", just because it's been pointed out that the changes you've been making could be improved further. Yes, you improve the article by changing the misuse of semicolon markup into the misuse of bold markup; but please explain what your problem is with marking up headers as headers, which is even better. There's no deadline for improving articles and if you don't do it, somebody else will. --RexxS (talk) 16:30, 24 March 2017 (UTC)

I have no problem with headings, just ones that are ==== inserted inappropriately====

because we haven't worked out a way to present an embedded list (such as musicians on an album) that won't cause problems for readers using a machine. We present this information in a list format because some people find it easier that way - they can glance at it, skimming through the list for names of interest. This skimming is inhibited by having headings. The solution in which we avoid using both headings and def list mark up to present these lists appears to work for both groups of readers, so it seems sensible to use it. SilkTork ^{✔Tea time}

You still haven't explained why headings like "Former members" are somehow

inserted inappropriately

to a subsection containing a list of former members – beyond making the bald assertion. Of course they are appropriate. Everywhere else on Wikipedia headings are used to title sections; why should that be inappropriate for bands? A heading is no better or worse than the bold markup visually, and always better from an accessibility perspective. You can indeed 'skim through' a long list for names of interest; in fact you can visually skip past multiple subsections to the single subsection that you're interested in, and skim the list there. Easy for you, isn't it? Now try to do that using a screen reader when the subsections have no headings. That's much, much harder. You have to examine each entry in each list. So feel free to put your aesthetic sensibilities above functionality for those less fortunate than yourself. I'm done trying to explain it to you. --RexxS (talk) 19:45, 24 March 2017 (UTC)

Alternate: real definition list

Current

Peacock Fethaz – lead vocals, rhythm guitar (2013–present)

Joe Shredder – lead guitar (2013–present)

Bill "Thumper" McGraw – bass guitar, background vocals (2015–present)

Joe Black – drums (2015–present)

Former

Thera Mihn – keyboards, background vocals (2013)

Campbell Rivers - bass guitar (2013–2015)

Jon Heron - drums, background vocals (2013–2015)

This should be referenced, but if references appear in the article for the line-ups and departures, it's not entirely necessary. This formatting satisfies accessibility guidelines as they are true definition lists. This formatting satisfies the concept proposed by SilkTork that some people find it easier to glance through a list format. It also removes the problem of short sections. It's also elegant because a bot (or Jennica) can go in to the many band articles that are formatted with a semicolon for a bold sub-heading style and convert the bullets under them to colons. I have actually used this formatting on several articles, but had other editor come change the colons to bullets.

If it's acceptable here, I would propose the change to the music project's manual of style. Walter Görlitz (talk) 17:54, 25 March 2017 (UTC)

Of course it's not acceptable here. Visually it creates exactly the same sections as using the correct heading markup, and from an accessibility perspective, it removes the screen reader's ability to go directly to a particular section. That's a step backwards for accessibility and we should have no truck with such suggestions. The correct markup uses headings as mandated by the MOS, and you'll need a very good reason to depart from that. --RexxS (talk) 19:07, 25 March 2017 (UTC)

There would be a heading here and it would be "Member". Since it's short, it would be clear what's being presented either to a screen reader or quickly visually scanned by the sighted. The music MoS could be modified and some limit could be suggested, such as "if any of the members list is longer than a dozen items, all of the members headings should be real so that they can be navigated to directly." That would mean bands like Chicago or others with large horn sections would keep the sub-headings, but four-member bands that have switched out a few musicians, as is displayed with this example, would not have the unnecessary short sections created by real headings. Walter Görlitz (talk) 22:17, 25 March 2017 (UTC)

Obviously this won't go well. I had changed the formatting to subheaders on several articles and was asked by another seasoned editor why I've been doing it. --Jennica✿ / ^talk 20:10, 26 March 2017 (UTC)

@Walter Görlitz and Jennica: It's quite right that in the case of the example you give, the benefit to a screen reader of being able to navigate to a subsection of "Members" is small. However, this isn't a specific article talk page, it's the Manual of Style Accessibility talk page, and we have to consider the cases where the subsections are larger and the benefit of headings is correspondingly greater. It's obvious that you're angling to create guidance for WikiProject Music that contradicts best practice as documented here. That would lead to cases where large band articles having multiple long lists of current and former members would still have your advice to use pseudo-headers, and then you'd be edit-warring to retain those pseudo-headers when somebody noticed that they clearly create unnecessary problems for screen readers. Personally, I don't care if the odd stubby music article doesn't adhere to best practice and uses bold markup to denote subheadings for very short sections; it's sub-optimal but not a big annoyance for those using assistive technology. But I do object strongly to you writing general advice that would codify poor practice in order to lend it a veneer of respectability, along with the potential to misuse any such advice and cause conflict in larger articles. --RexxS (talk) 23:55, 26 March 2017 (UTC)

And I've already provided a solution to "the cases where the subsections are larger and the benefit of headings is correspondingly greater". It really seems to me as though you're not reading what I'm writing. I'd like to hear from @TheDJ: and other editors. Walter Görlitz (talk) 03:41, 27 March 2017 (UTC)

I think i don't want to get further into this. I've said what I can say about this. Some people feel quite strong about their own opinions. I have no desire to be an arbitrator in this discussion. —TheDJ (talk • contribs) 07:38, 27 March 2017 (UTC)

Alternate: real headings

=== Current ===
(Introduction goes here.)
* Peacock Fethaz – lead vocals, rhythm guitar (2013–present)
* Joe Shredder – lead guitar (2013–present)
* Bill "Thumper" McGraw – bass guitar, background vocals (2015–present)
* Joe Black – drums (2015–present)

=== Former ===
(Introduction goes here.)
* Thera Mihn – keyboards, background vocals (2013)
* Campbell Rivers - bass guitar (2013–2015)
* Jon Heron - drums, background vocals (2013–2015)

--RexxS (talk) 19:07, 25 March 2017 (UTC)

This isn't acceptable though as it creates short sections. Since the members section is already short, there's no need to go directly to a former members section the real lists option is not a step backward at all. This suggestion isn't workable either. Walter Görlitz (talk) 19:29, 25 March 2017 (UTC)

It is acceptable because the markup does not create short sections. The short sections are created by the content, not the markup. The subsection containing the list of current members, for example, is exactly the same size whether its title is marked as a heading (accessible) or as any of the pseudo-headers that you're trying to justify (not accessible). There is only one solution that's acceptable from an accessibility perspective and that is headings. --RexxS (talk) 23:27, 26 March 2017 (UTC)

Double speak. It's a short section no matter how you slice it. A current and former members section is even smaller than the members section would be. Walter Görlitz (talk) 03:14, 27 March 2017 (UTC)

Pure nonsense. The sections and subsections are identical length whether they are marked up properly by headings or by the non-accessible pseudo-headings you want to force on everybody. --RexxS (talk) 12:21, 27 March 2017 (UTC)

MOS:LISTGAP

I changed some instances of the phrase blank line(s) to empty line(s), which was reverted here. The guideline is really referring to empty lines in the code as the problem. Both double line breaks and a line occupied by colons produce a blank line in the display; therefore I think that empty line is clearer and more precise. It's also consistent with the first sentence of the section: "Do not separate list items by leaving empty lines or tabular column breaks between them". Any objections to changing these two mentions back to empty line(s)? —Sangdeboeuf (talk) 14:13, 28 March 2017 (UTC)

"Blank" is idiomatically more correct. Better to keep as "blank" rather than changing back to the awkward "empty". Walter Görlitz (talk) 14:17, 28 March 2017 (UTC)

@Sangdeboeuf: Walter is exactly right. English idiomatically uses 'blank line' for a line that is devoid of text and that is precisely its meaning. My inclination would be to change 'empty line' to 'blank line' in the opening sentence. The accessibility problem is when editors separate list items with blank lines, not when they separate list items with lines consisting only of colons, as I have done here. Technically, neither double line breaks nor a line occupied only by colons actually produce a blank line in the display – all you are seeing is the margins (total 0.8em) between the list items that represent threaded comments. --RexxS (talk) 15:47, 28 March 2017 (UTC)

Mixing list types

I often see markup like this on Talk pages:

*
:*
::*

So I added it as another counterexample. Three seems like it might be a bit much, though… thoughts? —67.14.236.50 (talk) 23:49, 3 May 2017 (UTC)

Maybe handle the blank-lines and mixed-list examples separately? Like so:

Do not separate list items by leaving empty lines or tabular column breaks between them. This includes items in a description list (a list made with a leading colon) or an unordered list. Lists are meant to group elements that belong together, but MediaWiki will interpret the blank line as the end of one list and start a new one. Excessive double line breaks also disrupt screen readers, which will announce multiple lists when only one was intended, and therefore may mislead or confuse users of these programs. Such improper formatting can also more than triple the length of time it takes them to read the list.

For example, in a discussion, do Y this

* Support.  I like this idea.  [[User:Example]] 
** Question:  What do you like about it?  [[User:Example 2]]

but N don't do this:

* Support.  I like this idea.  [[User:Example]]

** Question:  What do you like about it?  [[User:Example 2]]

Likewise, do not switch between list marker types (colons, asterisks or hash signs) in one list, unless embedding a separate list within another list item. Do Y this best practice:

* Support.  I like this idea.  [[User:Example]] 
** Question:  What do you like about it?  [[User:Example 2]]

or Y this acceptable practice:

* Support.  I like this idea.  [[User:Example]] 
*: Question:  What do you like about it?  [[User:Example 2]] 

but N don't do this:

* Support.  I like this idea.  [[User:Example]] 
:: Question:  What do you like about it?  [[User:Example 2]] 

or N this:

* Support.  I like this idea.  [[User:Example]] 
:* Question:  What do you like about it?  [[User:Example 2]] 

—67.14.236.50 (talk) 23:55, 3 May 2017 (UTC)

The main thing that we should get across is that the order of the symbols is significant - outermost at the left and innermost at the right. Nested lists need not be the same type as their parents, but same-level entries in lists (nested or otherwise) must be the same type as their siblings. --Redrose64 🌹 (talk) 07:26, 4 May 2017 (UTC)

Agreed with RedRose about the main thing to get across. Obviously the only issue is how best to do it. I think giving examples is a perfectly satisfactory method of explanantion and I'm all in favour of 67.14.236.50's suggested layout which separates to some extent the issue of empty lines from that of switching list types. That's a good start, at least. --RexxS (talk) 11:43, 4 May 2017 (UTC)

Accessibility problem with Hanging indentation of refbegin

Hi, because the usage of : for indentation of references in {{refbegin}} is an accessibility problem, I'm proposing a new site wide class to fix the problem, so that we can go back to using unordered lists (*) for these types of usage. Feedback is welcome. —TheDJ (talk • contribs) 12:13, 4 May 2017 (UTC)

Template:Copts

I tried to fix some accessibility issues with Template:Copts, but my changes were reverted. any changes that help improve the usability or comments concerning the template are welcome on the talk page. thank you. Frietjes (talk) 16:12, 28 May 2017 (UTC)

I've commented, but more eyes on the discussion would be welcome. --RexxS (talk) 17:26, 28 May 2017 (UTC)

CSS in place of scrolling blocks

FYI

 – Pointer to relevant discussion elsewhere

The discussion Wikipedia_talk:Manual_of_Style#Scrolling lists? may be of interest. The summary: A <div>...</div> was being used with forced-on scroll bars to present a series of template-generated images (which can't be used in <gallery>...</gallery>). I replaced this with a CSS-based system that can be used, regardless of user agent, on arbitrary blocks of content to present them in a similar way that will auto-wrap to subsequent lines for narrow window width, without ever generating horizontal or vertical scrolling widgets.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:18, 10 July 2017 (UTC)

TfD: Template:Geographic_location

FYI

 – pointer to relevant discussion elsewhere.

Please see Wikipedia:Templates for discussion/Log/2017 July 20#Template:Geographic location, about which accessibility/usability questions have been raised, particularly the use of tables for decorative layout.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:20, 20 July 2017 (UTC)

Use of "No" for "No." or "number"

FYI

 – Pointer to relevant discussion elsewhere

The "Related matters: dropping the dot, and MOSABBR" subtopic of a thread about "No." and "Vol." at the main MoS talk page may be of interest to MOSACCESS watchlisters.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:40, 11 July 2017 (UTC)

@SMcCandlish: did we ever look at the usage of <abbr> ? I believe support for that is not stellar in screenreaders and I don't think we should be adding it all over the place, but maybe it would make sense for certain templates at least. —TheDJ (talk • contribs) 14:32, 25 July 2017 (UTC)

Does it break screen readers, or do they just not make use of it? We have templates that use it already, and if it doesn't cause breakage, it would be good to do more of it. I've also been thinking that various present-day screen readers are not doing many things that they should and eventually will (e.g. using a voice tone distinction between <em>...</em> and <i>...</i> markup, with the latter not being treated as emphasis, since it's often just around a foreign phrase, scientific name, or work title). We should be coding with the expectation that obvious improvements in such software will continue to happen over time.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:53, 28 July 2017 (UTC)

They just don't make use of it unless specifically told to do so by the user. I wouldn't hold my breath re screen reader improvements, frankly, except for ARIA support. Graham87 02:59, 28 July 2017 (UTC)

Mass page moves proposal

Wikipedia:Village pump (proposals)#Bot to move superscript.2Fsubscript pages to their correct location is a proposal to move pages so that the titles do not contain Unicode superscript or subscript characters. Part of the rationale is to make the page titles more accessibility for people who use screen readers. WhatamIdoing (talk) 17:11, 16 August 2017 (UTC)

Pseudo-headings

After this user talk discussion with Armbrust, I noticed that this page suggests pseudo-headings — lines of bolded text instead of semantic heading markup — are "acceptable".

Pseudo-headings squarely meet WCAG failure F2 and should be avoided. This page allows an exception when a real heading would blow up the TOC, but I think it should be more clear that this is a narrow exception, not generally acceptable.

On a related note, I submitted a patch to whitelist aria-level attributes. That way, pseudo-headings, if they must be used, can specify a hierarchical level, i.e. <div role="heading" aria-level="4">Pseudo-heading</div>. See WCAG's wiki page on using role="heading". Matt Fitzpatrick (talk) 00:37, 13 September 2017 (UTC)

The page never uses the word "acceptable" in connection with pseudo-headings. What it does say is that if you can't or won't use real headings because of problems with the TOC, then bold text in place of a heading causes less annoyance to screen readers than misusing half of a description list. if you can explain that better than the current wording, then I'd say go ahead and re-write it. ARIA is a good idea, but older screen readers don't use it (and the cost of updating JAWS is not inconsiderable). Even the latest versions of the software aren't 100% ARIA compatible – have a look at https://www.powermapper.com/tests/screen-readers/aria/ for some recent tests done on compatibility with some of the common assistive technologies.

So, my recommendation is keep pushing ARIA where you can, but don't assume it solves all the problems. Cheers --RexxS (talk) 16:34, 13 September 2017 (UTC)

People are supposed to read the ENTIRE set of guidance on headers, you cannot skip over all the rules and pick the "least desirable option" just because it suits you. But when it comes to choose between bad and worse, bold will at least not be prohibitive, it will just be like: a normal word in front of a paragraph. —TheDJ (talk • contribs) 19:06, 13 September 2017 (UTC)

I've added more words to clarify how F.. special your case needs to be before you can use them. —TheDJ (talk • contribs) 19:22, 13 September 2017 (UTC)

em instead of i for emphasis

Re: my recent edit, reverted

Wikimarkup '' '' in place of <i> </i> is fine and good. They come out as the same HTML element.

But here, <i> </i> is not the appropriate element. <em> </em> is. Authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis... — HTML5 spec. '' '' and <em> </em> are not interchangeable because they are not the same. Matt Fitzpatrick (talk) 20:58, 15 September 2017 (UTC)

I removed the markup in a subsequent edit because I don't see why emphasis is needed here (marked up correctly or not). Maybe these should indeed be italicized (but not for any desire for emphasis), but I didn't see a reason off the cuff. --Izno (talk) 21:04, 15 September 2017 (UTC)

I suspect that the original author wanted to stress that floating elements need to be placed **inside** a section (as opposed to outside of it). I mean that's the inflexion I'd use if I were trying to explain verbally. Anyway, Matt, I agree with your general point that <em>...</em> and ''...'' are not the same semantically, so your original intent was good. There's another debate, of course, about whether we should be using raw html in our source text, or whether we are better to use a template like {{em}}. This probably isn't the place for that debate, but my observation is that generally the preference is to use the template. Although lately I'm more persuaded by the argument not to proliferate templates because they are a stumbling block to translation into small language wikis where it's an extra chore having to keep checking whether a particular template even exits there (or if it's implemented identically to the one on en-wp). --RexxS (talk) 22:38, 15 September 2017 (UTC)

Now that I see this paragraph without any emphasis, I think it might be better without it. Matt Fitzpatrick (talk) 02:55, 16 September 2017 (UTC)

The diff in the OP shows an edit which included changing should be placed ''inside'' the section to should be placed <em>inside</em> the section.

I suppose MOS/Accessibility might need special markup so this page could be an exception, but there should be no suggestion that editors should patrol Wikipedia looking for opportunities to replace ''...'' with <em>...</em>. That would be a bad idea because pages use wikitext not pedantic markup and definitely not templates unless really needed. Johnuniq (talk) 23:47, 15 September 2017 (UTC)

My apologies. The em and italic do not equate to the same mark-up as I stated. Walter Görlitz (talk) 23:48, 15 September 2017 (UTC)

@Johnuniq: The question is mostly moot. Outside of quotations, use of <em>...</em> or {{em}} should be non-existent in mainspace because of WP:NPOV. (Similarly for <strong>...</strong> or {{strong}}.) As for pedantic, we have a mission to be accessible. We should indeed use the correct HTML to indicate emphasis, where it does occur. --Izno (talk) 00:15, 16 September 2017 (UTC)

Agreed with keeping <strong> and <em> out of article text without good reason. I'd caution, though, that ''' and '' for visual importance or emphasis would raise the same POV issue, just with loose semantics. Matt Fitzpatrick (talk) 03:07, 16 September 2017 (UTC)

(edit conflict) @Johnuniq: That's not right, John. There's no question of pedantry, but of genuine utility. Text that is rendered as italic in English may not be emphasised, but a foreign phrase or a book title, for example. The appropriate markup in other languages may be different between those cases – Japanese is one example. That means that if we merely use italic markup for a phrase, a translator may have to inspect the context to ascertain the correct translated markup; whereas if the phrase is specifically marked as emphasis, or foreign, or a title, then translation is simple enough even to be automated. All webpages should always use semantic markup where feasible - there's really no good reason not to. --RexxS (talk) 00:18, 16 September 2017 (UTC)

If the emphasis were to be retained then, yes, this was the correct way to do it (using {{em|inside}} also produces the same output). It's not true that "Outside of quotations, use of <em>...</em> or {{em}} should be non-existent in mainspace because of WP:NPOV"; we infrequently but sometimes importantly and legitimately use emphasis to make meaning clearer. There's a world of difference between clarity emphasis and emotive emphasis. MOS:ITALICS provides a good example of encyclopedic use of emphasis in the section on emphasis. Another good example is found in Faster-than-light: "In special relativity, it is impossible to accelerate an object to the speed of light, or for a massive object to move at the speed of light." As the examples show, it is most often used with short words that are usually skimmed over and sometimes treated as synonymous with other short prepositions, conjunctions, etc., but which in the particular context are very exact (another common case is the distinction between and and or in logic, maths, philosophy, and computer science material).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:07, 18 September 2017 (UTC)

Mass color changes

Are the changes by 71.208.205.180 desirable? Apart from sandboxes, the following have been edited so far.

• Module:Ulam spiral
• Template:3-el perm inversions
• Template:4-el perm inversions
• Template:Honeycombs
• Template:MoS guideline
• Ulam spiral
• Wikipedia:Manual of Style/Accessibility

Johnuniq (talk) 23:48, 28 October 2017 (UTC)

No, they have little effect and are done merely to satisfy the preferences of the IP. These are "Material Design colours" according to one of their early edit summaries – see https://material.io/guidelines/style/color.html – and there's no reason to pander to an editor who can't be bothered to communicate. --RexxS (talk) 00:21, 29 October 2017 (UTC)

Thanks! I'll check for more later. Johnuniq (talk) 03:17, 29 October 2017 (UTC)

FWIW, the color (hue) changes at Template:Honeycombs appear to be an improvement (the original and current-again colors are so washed out as to be pointless), while the changes there to shades (greyscales) were not, being too dark for the text and background to have sufficient luminosity difference.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  09:24, 30 October 2017 (UTC)

Washed-out background colours are an inevitable consequence of trying to ensure that text and hyperlinks are readable against that background for all combinations of visual and colour impairments. Meeting WCAG AAA standards leaves much less room for background colour variety than many editors wish. Of course, the grey background chosen by the IP didn't meet Snook's Colour Contrast Check. However, the current header background colour doesn't meet it either. If we want to retain the "lightsteelblue" hue, that header background needs to be lightened and desaturated to at least #E6F4FF to meet WCAG AAA & contrast for the links. --RexxS (talk) 14:04, 30 October 2017 (UTC)

That sounds worth doing. As for the hues, I and others could likely get used to it, if the site were redesigned to look that way consistently. The problem with the present wash-out look in that template is that it's jarringly different from the rest of the site, including most of our tables that use background colors. It probably makes more sense to establish a norm and then impose it on templates generally, rather than doing it to one here and another there.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  00:33, 31 October 2017 (UTC)

You're quite right about consistent looks. The devs are looking to establish a series of colour palettes that are guaranteed to meet WCAG standards. One example is https://phabricator.wikimedia.org/T109915 and there are links there to related ongoing tasks. I've been encouraging them to try to meet WCAG AAA as often as possible, but that's quite hard. Personally, I'm happy with the defaults for wikitables, etc. but there are just too many editors who want to make the encyclopedia "colourful" with little regard to any visual impairments. "Skittlepedia" as my old pal Jack Merridew used to call it. --RexxS (talk) 00:47, 31 October 2017 (UTC)

Yeah, I try to fix luminosity/contrast problems when I encounter them (like black-on-red, etc.), and also regularly tone-down "neon" colors.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:14, 31 October 2017 (UTC)

Screen-reader effects of "prime" characters

At Wikipedia talk:WikiProject Chemistry#Typography of primes, I started a discussion of how we should write the prime (symbol). In this context, I think the symbol should be read literally ("N′-methyl" as "en prime methyl"). How do screen readers handle the &prime; and related entities? Feel free to follow up in that discussion for this or other accessibility aspects. DMacks (talk) 06:27, 24 November 2017 (UTC)

Accessibility versus convenience in indentation (RfC at VPPOL)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Village pump (policy)#RfC: Accessibility versus convenience in indentation
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:38, 3 December 2017 (UTC)

Discussion at Talk:2014–15 A-League National Youth League#Pseudo-headings

You are invited to join the discussion at Talk:2014–15 A-League National Youth League#Pseudo-headings. -- Marchjuly (talk) 07:20, 4 December 2017 (UTC)

List of former cantons of France

The article List of former cantons of France has a single table, with headings inside table rows. Disregarding the disagreement over whether those headings should be level 2 or level 3 (I know that level 2 is the only one meeting accessibility guidelines) for the moment, and looking only at the matter of headings inside a table, how is it for accessibility? I found the article via User talk:Ladsgroup#Stopping Dexbot on an article, so am notifying Ladsgroup (talk · contribs) and Eno Lirpa (talk · contribs). --Redrose64 🌹 (talk) 23:34, 6 December 2017 (UTC)

It's not actually an accessibility *problem* per se ... but it's just plain weird, and I don't know how to explain why. For example, NVDA reads the table row number each time I move between headings, which I guess is helpful, but it just sounds ... odd. Graham87 02:06, 7 December 2017 (UTC)

I wanted the full set of information to be sortable by canton name and by departement name, so that canton can be found alphabetically, but also cantons can be found by departement by sorting on departement. If I used separate tables, each in its own section then this is not possible. By placing the section headings inside the table, spanning all the columns, then the section headings also sort correctly for sorts on either canton or departement, that is the section headings get placed correctly for departement when sorted by departement, and obviously allows sorting over the full set of information. Regards. Eno Lirpa (talk) 13:53, 7 December 2017 (UTC)

It's a bit odd, but not prohibitively so for accessibility I think. Just don't be surprised if it breaks, because it's very reliant on how we currently parse a page, and i'm not sure with the deprecation of Tidy and the addition of the sectioning api for mobile, if this will continue to work for perpetuity. —TheDJ (talk • contribs) 14:25, 7 December 2017 (UTC)

Whether it's an accessibility problem or not, it's an HTML a layout structure problem, and should be replaced. The thing to do here is to use id attriubutes on the <th> (!) table headers (A, B, C, etc.), to create anchors, and then use a custom ToC to point to the anchors.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  01:02, 8 December 2017 (UTC)

The general problem with that, SMcCandlish is that folks like Graham often rely on their screen reader's ability to call up a list of headings as their principal method of navigation, rather than the TOC. That means we can't assume that anchors will duplicate all of the functions of headings. In this case, however – given the confusion that headings inside tables already produce – I believe your proposal would represent a distinct improvement. --RexxS (talk) 12:04, 8 December 2017 (UTC)

What do you think, Graham87, since you're our go-to personage for the "ground truth" on this accessibility stuff?  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  12:33, 8 December 2017 (UTC)

@SMcCandlish: I think your solution is probably best in this case. If all else fails, screen reader users can just whiz down the table really fast by holding the next row key down until they get where they need to go. Graham87 14:34, 8 December 2017 (UTC)

PS: Are the ToCs really not helpful? Given that they're (usually) built by making a list of the headings, it's seems odd and sad that it would be more convenient for screen-reader users to make their own such list on the fly. If they really do use our ToC, then no big deal; one built manually from anchors should work just as well.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:33, 9 December 2017 (UTC)

Yes, I use TOCs occasionally, but more for making links to sections than anything. I generally use my screen reader's next/previous heading navigation keys to move between headings in an articles. Graham87 07:16, 9 December 2017 (UTC)

If you think about it, SMcCandlish, it's far easier for a sighted visitor to spot the TOC and pick which heading they want, whereas for anyone using a screen reader, the TOC is just another <div>...</div> with links in it - it has to be navigated to each time you want to use it. On the other hand someone using JAWS just has to press H or shift-H from any point in the page to jump to the next/previous heading and hear it. There's also Insert-F6 to open the headings list dialog box, so it's not surprising that folks using screen readers find well-organised headings very useful when navigating any web page. HTH. --RexxS (talk) 13:03, 9 December 2017 (UTC)

Hmm. Now I wonder if explicit <h#>...</h#> markup with a class might help (especially if templated), so that heading markup is used without the visual overhead of the default heading styles. At the HTML level, technically it's valid to have headings inside a table; it just looks like ass in a Wikipedia page. Regardless, it doesn't make any semantic sense in a regular cell rather than in the table header cell.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:21, 9 December 2017 (UTC)

Results of RFC

The recent RFC at [1] showed that there is not consensus for a general requirement that articles should stop using colon for indentation. The use of colons is a current, standard practice. It's no problem for this guideline to give optional advice, but given the outcome, it would be inappropriate to add any language that suggests that colons are deprecated, legacy, outdated, or otherwise not the standard way of doing various kinds of indentation. — Carl (CBM · talk) 12:14, 13 December 2017 (UTC)

Nah. This blatant and falsely-worded canvassing showed that the RfC was derailed by a bloc vote from one special interest group who did not understand the wording of the RfC. It's a WP:FALSECONSENSUS. But, it's a moot point. No one tried to "ban" using colons for indentation anyway! The RfC had literally nothing to do with that at all, only with whether two editors can filibuster against MoS subpages agreeing with the main MoS page. You're also confusing "used by many because it's convenient and we started out that way when WP was new" with "standard". They're not synonyms. When three MoS pages have agreed for years that there are better alternatives, and we know for a fact that doing it the colon way causes validation failure, and that there are better and more robust ways that are well-tested (one of them actually standardized as a template for this purpose on every single WMF project), and the page you're "defending" has nothing whatsoever to do with accessibility and layout, then it's time for you to WP:Drop the stick.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:04, 13 December 2017 (UTC)

That's completely missing the point, Carl. The use of colons for indentation is a long-standing, common practice. It is also bad practice, and it does nobody any favours by pretending otherwise. Good grief, most sensible web designers stopped using definition lists to produce visual indentation before the turn of the millennium, and you won't find a single other large website making that mistake. We ought to be encouraging better practice by offering editors alternatives that don't cause a nuisance to our visually impaired visitors. Using description lists for indentation is an accessibility issue, period. No amount of RfCs can alter that fact, and this page is quite right to point that out.

Now, don't misunderstand me: I'm not suggesting banning the use of colons for indentation. There are simply too many talk pages and archives with that poor markup to even consider that option, and Wikipedia editors who use screen readers will have become accustomed to the second-rate experience afforded by our ignorance. But there's no good reason why articles ever need to use colons for indentation, other than in conjunction with semi-colon markup when genuine description (definition) lists are actually required, as in a glossary or lists of characters and their characteristics in articles about TV series, for example. --RexxS (talk) 19:02, 13 December 2017 (UTC)

I get the distinction between an ideal world and the actual world. But the issue I am looking at here is only: does the use of colons to indent non-blockquotes comply with the MOS? The answer to that has always been a clear "yes". A change to that longstanding aspect of Wikipedia style requires much more than just the input of a few editors here, or an undiscussed edit to an MOS page. It needs to be widely advertised at least on a village pump, and have a clear consensus, before changes to the MOS. Those changes would then need to be clear about what the MOS does require. At the same time, I don't object to the language here being changed provided that it remains only advisory, as it has been for a very long time, and not prescriptive. — Carl (CBM · talk) 20:36, 13 December 2017 (UTC)

But you don't seem to get the distinction between what we need to do to improve the experience of reading any web page for a user of a screen reader and what has been accepted in ignorance as suitable markup for Wikipedia. That is the only issue that applies to this page. That's neither negotiable, nor susceptible to crowd-sourced wisdom. It's just a fact. That means that you're mistaken about the answer to does the use of colons to indent non-blockquotes comply with the MOS? Ever since the decision to make WP:ACCESS part of MOS, the answer to that question is a clear "no". The documentation provided by our policies and guidelines is descriptive, not prescriptive, and the MOS cannot require anything, so it's not going to force anybody to improve their bad habits. It might just encourage them, though. We don't need an RfC to make clear what should be done to improve the accessibility of Wikipedia, and the language here will continue to make that clear, despite a handful of editors at minority projects choosing to attempt to defend the indefensible. I don't object to you writing whatever takes your fancy at MOS:MATH as long as you don't try to remove guidance on best practice about accessibility in MOS:ACCESS. --RexxS (talk) 01:14, 14 December 2017 (UTC)

The MOS requires many things. For example, WP:MOS requires "In generic use, apply lower case to words such as president, king, and emperor". This is not descriptive - it is explicitly prescriptive, and all articles are expected to comply or be fixed. By contrast. most of the advice in WP:ACCESS is just advice (basically: "you can do this if you want, but there is no requirement, and you are free to ignore it if you want"). That is how the use of colons for indentation has always been treated by WP:ACCESS. In contrast, WP:ACCESS forbids the use of blank lines between colon-indented material ("Blank lines must not be placed between colon-indented lines of text"). There is an important difference in the way these things are worded. At the RFC, quite a few editors were explicit that colons should remain an acceptable way to indent material, just as they have always been. The accessibility issue should be handled, of course, but by improving Mediawiki rather than by changing the standard method of indentation. — Carl (CBM · talk) 01:27, 14 December 2017 (UTC)

I am also fine with the longstanding wording here, as I think I have indicated - if not, that's the point of this follow up. Everything was very stable until quite recently, which suggests to me that was not actually any important disagreement in the way that the two pages WP:ACCESS and WP:MOSMATH have been read for years. — Carl (CBM · talk) 01:35, 14 December 2017 (UTC)

On the contrary, the MOS does not require that lower case be applied to common nouns. It gives guidance that lower case should be applied. Take a look at Malignant Metaphor: Confronting Cancer Myths which has lots of common nouns capitalised. There are thousands of articles with the same problem and editors have freely ignored what the MOS advises for as long as the MOS has existed. The way it works is that the MOS gives guidance that carries authority. An editor will follow the guidance of MOS to fix problems and the onus falls on anyone disagreeing with that in a particular case to demonstrate why an exception should be made.

Now, when someone fixes colon markup in an article by use of an accessible alternative, what you want is to be able to tell them "Oh no. You can't get rid of my inaccessible markup. I'm allowed to use it by the MOS." Well that simply isn't going to fly, is it? That wouldn't be using the MOS to promote good practice, just to defend a set of personal bad practices.

As for blank lines, MOS:ACCESS tells editors not to place blank lines between colon-indented lines of text. It doesn't stop them from doing it, of course, but it does justify fixing that issue when it arises.

In the RfC, some editors did ask that colons should remain an acceptable way to indent material, despite the problems they cause for the visually impaired. But like you, they fool themselves into thinking that improving Mediawiki will solve the accessibility issue. It can't. Colon markup is being used for two distinct purposes in Wikipedia: (1) to complement semi-colon markup in the creation of description lists; and (2) to create visual indentation at the expense of causing accessibility issues. Until somebody figures out how to replace either all of the semi-colon/colon markup for genuine description lists, or all of the colons used just for visual indentation, any change to the way that colon markup is parsed by Mediawiki software will cause chaos. If you contend I'm wrong about that, then feel free to submit your patch to the Mediawiki software that fixes the issues. Until you're willing to do that, you really ought not to be stonewalling positive steps to reduce the accessibility problem. Nobody needs colons in articles just to produce indentation, and it's a step forward to point out the accessible alternatives. --RexxS (talk) 02:13, 14 December 2017 (UTC)

A few points I would add to what RexxS said: "Everything was very stable until quite recently" ... because keeping MoS material in sync requires real and often slow actual human effort, and because MOS:MATH is obscure, and is over-controlled by people from WP:MATHS with almost no input from MoS regulars. Did you know that WP:MOSNUM (the page where nearly everyone goes for any MoS-related material involving numbers) did not even mention MOS:MATH, until I fixed that yesterday? You're welcome. The only "instability" in this situation was the two-editor flipout over nothing but recommending and illustrating more accessible markup that produces visually identical output and has no effect at all on the math markup. Total overreaction.

On "forbid" and "require": MoS, being a style guide, prescribes (advises, provides guidance to do or not do) many things. Due to the WP:POLICY rules about what a guideline actually is and isn't at Wikipedia, and by MoS's own lead, it cannot literally forbid or require anything, whether it's emphatically worded or not. (Much of its more authoritarian language was added by a single party who later got topic banned; we've been slowly moving it back to more advisory wording; I do a lot this rewording myself – including today, specifically to mollify CBM's and SB's concerns [2]).

The idea (or at least one of them) at Phabricator ticket T6521 is for the MW parser to detect whether a :-starting line is preceded by a ;-starting line and vice versa; if not, convert to a styled span instead of list markup. There's lots of whingeing that this is hard, but MW is a marvel of making hard stuff practical, so I have faith it can be done right. It's just a matter of whether the devs finally take it seriously enough to actually make it happen. It can also happen that <math> can be modified to support an indentation attribute; these are complementary not competing ideas. There's an obvious logic problem here, though: the naysayers' objection at WT:MOSMATH and at the train-wrecked RfC – that there's so much math markup already indented by colons that it's just too hard [wailing sound effects here] to change it – is disproven by their support for changing <math>, which would take exactly the same amount of work to implement in the articles. The hominid territorial instinct – "if it's not my tribe's plan it's an attack" – must be conscientiously suppressed by all of us here.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  05:49, 14 December 2017 (UTC)

I do not think casting this as a tribal overraction is remotely constructive. Nor is singling out two editors who have made far fewer edits to the guidelines as being on a "rampage", simply because they happen to have a different opinion than you. So, if you wish this discussion to move forward, such characterizations really must be stopped immediately. They are totally against policy, as you've already been reminded.

On to the more substantive WP:ACCESS issue, I do not see how using a special template, which would involve typing the special characters "{", "}" that require additional navigation to a menu of special characters, four times, on a mobile device, is more accessible than typing the single character ":". Do folks editing with screen readers actually find it more accessible to use a multicharacter solution, including four special characters? Evidence to the contrary exists on this very talk page is that User:Graham87, who I believe uses a screen reader, uses colons for indentation. If not, then it seems to me that the only solution here is to fix the emitted HTML. This was raised several times at the RfC in question. Indeed, it seems like consensus (insofar as there was one) coalesced around that very suggestion. This would have the added benefit of fixing talk pages: I note that all participants in this discussion themselves use colons for indentation. Sławomir Biały (talk) 14:03, 14 December 2017 (UTC)

I'm afraid you've completely missed the point of Wikipedia. We're writing this encyclopedia for the readers, not the editors. If an editor finds it awkward to type "{{ }}" on a mobile device, I sympathise with them – it is awkward – and that's why I edit from a desktop PC. But that sympathy and consideration does not override the duty we owe to our readers, a significant number of whom use assistive technology to read our articles, and they will find our broken definition lists used to indent confusing and awkward, a problem they will not have encountered on any other major website.

Like everyone else, Graham87 included, we use colons to indent comments on talk pages. After all, it's all we have, and as editors, we get used to it. But the same argument simply can't be applied to articles, particularly as the audience is completely different. Now Graham is a really nice guy; I've had the pleasure of meeting him in person, and he is remarkably good at making allowances for all the crappy markup we throw at him, but he has been able and willing to get used to it. Nevertheless I'm not prepared to tell every visually impaired visitor that they have to "get used to it" as well, simply to make life a bit easier for editors who find it hard to type "{{ }}}" on their phones. That really would be the tail wagging the dog. I hope that helps you understand why I'm so passionate about these accessibility issues, and why I want us to give advice to encourage the very best practice possible. And that doesn't mean encouraging colon markup to produce indentation. --RexxS (talk) 17:09, 14 December 2017 (UTC)

And folks here assure me that the reader's experience will be improved if the developers fixed the broken semantics of colon. (I'm not convinced that it makes a big difference, but I will take your word for it that it does.) This will allow editors to continue to use colons for indentation on talk pages, for indenting equations in articles, and using the style guidance of this guideline. That seems to me like the solution. Sławomir Biały (talk) 17:56, 14 December 2017 (UTC)

There are no broken semantics of the colon markup to fix. The wikimarkup parser takes the colon and renders the html <dd>...</dd> tag. If the tag is not inside an html <dl>...</dl>, it adds that as well. However, that leaves the html missing the <dt>...</dt> element, which would be created by semicolon wikimarkup. A genuine description list has perfectly good semantics and, for example, glossaries using ; and : together for that purpose are commonly (and accurately) used in Wikipedia. However, if you now want to re-purpose the colon to mean style="left-margin:1.7em;" – an accessible method of indentation – then you break all of the uses of colon in glossaries, etc. for making a definition list. Having the same wikimarkup produce two different results in html/css depending on context is a fundamental no-no, and I'm not surprised the devs won't touch it with a barge-pole. I know that SMcCandlish has a touching faith in the devs' abilities to figure out when a colon is intended to be associated with a semi-colon (a genuine description list), and deliver different code from when a colon is meant to simply produce an indent, but I'm not convinced. I can see far too many opportunities for that to break – a description list inside an indent and an indent inside a description list come to mind immediately, not to mention a description list followed by an indent – for us to have any chance of a robust solution to the issue within a reasonable timescale. --RexxS (talk) 19:44, 14 December 2017 (UTC)

That's all correct (including my faith in devs to make it work). However I did say at the Phabricator ticket that since 99.99% or so of use of : is for visual indentation, not description/definition/association lists, that if the price we pay for fixing it is that it no longer ever does <dd>...</dd> that is acceptable triage, since a) it's not that much to clean up, comparatively, b) we have better markup for d-lists anyway, and c) the : way of doing is is actually extremely brittle (e.g. it breaks the list if you insert a linebreak in the item). It's anyone's guess what the devs will actually do, if anything.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:15, 14 December 2017 (UTC)

Colons mean indentation in Wiki. Furthermore, they have since the beginning. The software implementation of those semantics, regarding the colon as part of a colon-semicolon pair, is incorrect. That should be corrected. Sławomir Biały (talk) 21:49, 14 December 2017 (UTC)

That's patent nonsense. Colons have never meant indentation at any stage of the development of MediaWiki markup. The have always produced <dd>...</dd> html, just as semicolons have always produced <dt>...</dt>. It's true that most browsers have visually displayed the <dd>...</dd> as indented, and 20+ years ago early web designers sometimes misused <dd>...</dd> to create indentation. That particular bad idea died out everywhere except for the early MediaWiki users. As long ago as 2003, the misuse of dd to produce indentation was described as outdated:

Unfortunately there is no "indent" function in standard HTML, so in the past, designers resorted to the creative misuse of existing tags to get text to indent.... HTML cheats include ... Using a dictionary list (<dl>...</dl>) with only definitions (<dd>) and no terms to display text as indented

So why are some editors still fighting to retain a practice that was recognised as inappropriate 14 years ago and more? --RexxS (talk) 22:53, 14 December 2017 (UTC)

Well, Help:Wikitext and WP:INDENT, and you just used colons to indent. For a more historical viewpoint, compare Help:Editing circa 2001. shortly after the project launched. The (lack of) inclusion of indentation tags in HTML is a completely separate issue from the use of colons on Wikipedia. Colons are the standard way to indent in wikitext. I completely agree there is an issue in the way that Mediawiki renders indentation, but that does not mean that colons are not the standard way to indent things (several people also pointed this out in the RFC). — Carl (CBM · talk) 23:40, 14 December 2017 (UTC)

Well doctors used to bleed patients to let out foul humours and that was standard practice. That didn't make it good practice, did it? "Standard" does not equal "good", and it's about time you gave up hiding your lack of argument behind your mistaken assumption about what "standard" implies.

Of course I used colons to indent here. This is a talk page and editors have learned to accept the broken markup. I have to follow the nested description lists already in place because if I used CSS indentation, it would unwind other editors' nesting and cause an even greater mess.

The MediaWiki software does not render indentation. Your browser does that. If you used a different user agent (say Lynx or JAWS), you'd observe a different rendering from what you get using Chrome. MediaWiki consistently produces description lists from colon indentation and that is not the issue. The issue is simply that editors have chosen to misuse <dd>...</dd> to display indentation in a way that is inaccessible, so that the same markup (:) is being used for two different purposes. There are accessible alternatives to using colon markup for indentation, and I have yet to see any argument why an editor who changes a colon in an article to an indentation template shouldn't be congratulated for improving the encyclopedia, not lambasted for breaching some wholly imaginary "standard". --RexxS (talk) 11:19, 15 December 2017 (UTC)

Mediawiki renders wikitext (its input language) into HTML (its output language). Of course the browser then renders the HTML into a sequence of commands for a windowing environment, which eventually renders those onto a screen. I have not seen anyone arguing that Mediawiki should use dd/dl tags for indentation, but that is a completely separate question from how indentation is specified in Wikitext. In any case, I am OK with the current language of this page, which remains descriptive, and I don't see much benefit in continuing to go back and forth on topics that don't directly relate to changes in the page. If I see a reason to rejoin the conversation, I'll come back. — Carl (CBM · talk) 11:32, 15 December 2017 (UTC)

Mediawiki renders wikitext into html, but it does not render indentation. The user agent is responsible for that, so your statement "there is an issue in the way that Mediawiki renders indentation" makes no sense, does it? MediaWiki doesn't use tags for indentation, so your statement "I have not seen anyone arguing that Mediawiki should use dd/dl tags for indentation" is equally nonsensical.

The issue is no more that this: (1) editors choose to use colons alone to imply indentation; (2) mediaWiki transforms colons to description lists; (3) that results in broken html that causes accessibility problems. You want to break that chain by some unspecified – and wholly improbable – change to step 2. I want to tackle the problem at source by discouraging step 1 because we can do that now. There's where our disagreement lies. --RexxS (talk) 11:48, 15 December 2017 (UTC)

Carl, please stop resorting to this "you just used colons to indent" bullshit. Everyone in this so-called debate, on every page you've dragged it out across, explicitly recognizes that we use colons for indentation on talk pages and will continue to do so, unless and until WMF provides us with functional threading software that also handles MediaWiki code samples properly. This has nothing to do with preferring more accessible markup in actual article content. All of this has been pointed out to you several times, including at your own user talk page. If all you can do is childishly fall back on "you just used a colon", this means you have no argument left, and need to just drop the stick and go do something constructive instead of continuing to try to tell accessibility specialists what's-what about accessibility. See Dunning–Kruger effect and First law of holes.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:13, 15 December 2017 (UTC)

References

Alternative text for images

FYI

I moved WP:Alternative text for images to WP:Manual of Style/Accessibility/Alternative text for images, where the rest of the MOS:ACCESS supplement pages are. All links and shortcuts to it work, it just now isn't lost in the vast sea of the "Wikipedia:" namespace, but is consolidated with the related material. Also fixed the old WP:ALTPDI and MOS:ALTPDI shortcuts to work (they'd lost their anchor point when the "Purely decorative images" heading went away).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:53, 20 December 2017 (UTC)

"Animations; video and audio content"

"Animations, video and audio content" looks like typo for "Animations; video and audio content", "Animations – video and audio content", or something, because the construction isn't parallel.

This is minimally reparable with a serial comma: "Animations, video, and audio content". It's not perfect but it's more easily parseable without having to do a double-take and a head-scratch. Please see MOS:SERIAL: Use a serial comma by default, and definitely when the result is weird without one: "A serial comma (also known as an Oxford comma or a Harvard comma) is a comma used immediately before a conjunction (and or or, sometimes nor) in a list of three or more items .... Editors may use either convention so long as each article is internally consistent". This page is already using the serial comma ("... a substitute for the image for blind readers, search-spiders, and other non-visual users", etc.). While MoS doesn't technically apply to its own content, we try to keep it in compliance with it as a best practice, or it looks hypocritical to not do so, inspiring editors to ignore it when writing articles, and venting on the MoS talk pages about MoS not taking its own advice.

This would actually be better with more of a rewrite. Any of these would work:

• "Animated, video, and audio content"
• "Animated, video and audio content" – if people really want to go to war against a comma
• "Animations, videos, and audio content" – the comma cannot be omitted in this one
• "Animations and other audio-visual content"
• "Animated and other audio-visual content"
• etc.

An argument can also be made that "Animat[ed|tions]" is actually redundant with "video[s]" anyway.

This short version is: omission of the serial comma is lazy journalese, is not found in most academic writing, and makes it more difficult to tell that a list is a list and what is or is not a discrete item within it. There's a reason that The Chicago Manual of Style and other style guides that aren't for newswriting recommend it.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:03, 22 December 2017 (UTC)

Most of the early image animations were animated gifs and they were not conventionally considered video, although technically there's little difference. So to most folks' minds, I expect animations not to be redundant with videos. Any heading that needs time to be decoded is a candidate for re-writing. Personally I'd prefer the much clearer "Animations and other audio-visual content" which eschews the comma. --RexxS (talk) 23:31, 22 December 2017 (UTC)

I do, too, especially given that we use more animations than actual video (or it seems that way to me – this could be a factor of the kinds of articles I read and work on). However, just "Audio-visual content" would probably work fine, now that I think about it, if people like that concise option. But eschewing a comma isn't actually a good reason to do a rewrite; except in terrible writing (like the bad example given at MOS:COMMA), such punctuation doesn't decrease clarity, but increase it at near-zero cost. That said, I'm not going to argue further on it, and I apologize [3] for the grumpy WP:REVTALK about this; I was in a crabby mood for external reasons.

PS: I created the DAB page WP:Manual of Style/Audio as a place for the then-missing but obvious MOS:AUDIO to go; I think I included every relevant page, but could have missed something. Need to do similar for MOS:VIDEO.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:12, 23 December 2017 (UTC)

Sorry, I really wasn't clear there. I meant to say "I prefer this title for clarity. As a bonus it avoids arguments about commas." Maybe my original comment needed a comma in there somewhere? --RexxS (talk) 17:52, 23 December 2017 (UTC)

Short descriptions

FYI

Wikipedia talk:Manual of Style/Layout#Short descriptions. --Redrose64 🌹 (talk) 20:55, 17 February 2018 (UTC)

Discussion notice: Observe MOS:FONTSIZE in infobox templates

You may be interested in the proposal/discussion at Wikipedia:Village pump (proposals)#Observe MOS:FONTSIZE in infobox templates. ―Mandruss ☎ 00:27, 17 March 2018 (UTC)

Fake heading template use in articles?

Does the use of Template:Fake heading comply with MOS:GOODHEAD and WP:PSEUDOHEAD?

In this diff an editor removed the normal headers to use the fake heading template. I don't think this is the intended use of this template, but clearly it is happening regardless. I also don't think this template should be normally used in article space. In addition, I don't think this template supports anchors.

I started a conversation about this template on its talk page here: Template talk:Fake heading#Using this in articles? Does it comply with the MOS in article space? but I also wanted to see if there should be an explicit mention of not using this template in MOS:GOODHEAD and WP:PSEUDOHEAD. I don't think it complies with those guidelines and I think it should be made clear that this template should not be used in articles. Thanks, - Paul^T+/_C 16:58, 18 April 2018 (UTC)

It is really bad practice to make something out to be a heading when it's not actually marked up as a heading. It is markedly inaccessible as a result. There's probably a valid TFD to get consensus on where this template may be used (outside mainspace is probably appropriate/livable). --Izno (talk) 18:52, 18 April 2018 (UTC)

List of Philadelphia neighborhoods

I noticed that this revision of List of Philadelphia neighborhoods contained some quite extreme accessibility issues because it used tables for layout and also created gaps in the HTML list for each column. I made some grammatical corrections to the article, then I tried to convert the page to use divs, based on the examples below. Per WikiBlame, it looks like the tables were added by Roesluna, a blocked sockpuppet, in July 2013, then Bgwhite (who seems to be inactive now ... what a pity!) fixed some of them in July 2016. Any review of my edits from sighted people would be appreciated. Graham87 16:35, 22 April 2018 (UTC)

I think that there is a column width problem. Whilst setting |colwidth=15em is fine where the individual list items are short, this is not the case for a number of the list items which are quite lengthy. In some cases (such as those for Washington Square West and Southwark) the entry can wrap to twelve lines. But if I double the column width of the affected lists to |colwidth=30em, the shorter entries (which are in the majority) acquire extra blank space. This may be a content issue - the longer entries could be trimmed to eliminate excessive detail. --Redrose64 🌹 (talk) 07:03, 23 April 2018 (UTC)

Tooltip in RfD

One month late, but people would likely be interested in this discussion on {{Tooltip}} Galobtter (pingó mió) 09:30, 9 May 2018 (UTC)

Accessible design standards

Editors here may be interested in the work being done at w:pt:User:Danilo.mac/Padrão visual. Whatamidoing (WMF) (talk) 18:04, 25 May 2018 (UTC)

Edit Source

I notice this is all about using the classic code editor, without saying so. Should it say so, and say something about the Visual Editor and its impact, if any? Jim.henderson (talk) 12:45, 1 June 2018 (UTC)

"Timeline" under "Band members"

You may have seen (or not, even if they were there!) the multi-colored timelines on some articles for musical groups. Many, if not all of them, strike me as inaccessible for those with visual challenged, including color blindness. My eyes still work decently, but I'm already have a hard time with some of them in terms of color, contrast, thickness of lines (especially combined lines), etc. For a practical example, see Talk:IV_of_Spades#Timeline, where I'd like to have input from editors who know about these things. Disclaimer: I am opposed in general to these timelines, which IMO add nothing to the article UNLESS there is a good reason to have one, like in the case of bands that have gone through many lineup changes. Plus, I wonder how screen readers handle this. Drmies (talk) 15:34, 5 June 2018 (UTC)

At The Rolling Stones (which is a GA) the lineup changes have been complex enough that I can see the use of a timeline, but the colors there are surely in violation of accessibility guidelines. The purple on blue isn't clear even to me. Yngvadottir (talk) 04:35, 6 June 2018 (UTC)

Accessibility was never raised as a concern when implementing timelines and selecting colour schemes. Wikipedia talk:WikiProject Musicians/Archive 8#Create Member Section/Timeline Standards. Walter Görlitz (talk) 04:49, 6 June 2018 (UTC)

It turns out Graham87 was complaining in 2006 about the output of an extension used to create them: see Talk:IV of Spades#Timeline and archive discussion here. Yngvadottir (talk) 14:33, 6 June 2018 (UTC)

Table template

{{DemogFR}} seems to produce a table, but it wraps onto multiple lines (see the large table in Saint-Faust#Population). Is this more accessible than it looks? WhatamIdoing (talk) 20:17, 12 June 2018 (UTC)

It makes a table having four rows and one column. Each of those four cells contains one two-row table having nine or ten columns. The whole thing would be better organised as a two-column table having as many rows as necessary. --Redrose64 🌹 (talk) 22:25, 12 June 2018 (UTC)

That would be great for screen readers, but unfortunately a table with 37 rows, each containing two 3- or 4-digit numbers will create a huge amount of whitespace in normal browsers, so editors will complain about that. As the information is simply a long list of number pairs, I'd have coded it as a list (perhaps unbulleted) with each list element looking something like: 1793 - 764. Then we could use CSS such as {{div col|colwidth=20em}} to mop up the whitespace. --RexxS (talk) 02:40, 13 June 2018 (UTC)

Well, maybe some of that whitespace could be filled. Could the table be floated, and let the other text wrap around it? Or run a string of photos next to it? WhatamIdoing (talk) 06:22, 18 June 2018 (UTC)

Images as titles in navigation templates

I would appreciate input about the use of images as titles for infobox navigation templates at Template talk:S-rail/lines#Revert. Pi.1415926535 (talk) 22:12, 2 July 2018 (UTC)

Proposed addition on syntax highlighting (maybe at MOS:COLOR)

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style#Misuse of code syntax highlighting.

WP:Manual of Style/Accessibility#Color seems like the likely place to add material about this.
 — SMcCandlish ☏ ¢ 😼  12:53, 25 June 2018 (UTC)

This could still use further input.  — SMcCandlish ☏ ¢ 😼  06:12, 3 July 2018 (UTC)

Indentgap

FYI

Regarding WP:INDENTGAP, see User talk:Redrose64#Blank lines in talk pages. In particular, please observe the comment by Jc3s5h (talk · contribs), who wrote "I am not prepared to accept this guideline at all". --Redrose64 🌹 (talk) 20:14, 3 July 2018 (UTC)

Comment was here and @Redrose64: you should be asking your questions where the guideline exists, not in an unrelated page. Walter Görlitz (talk) 20:22, 3 July 2018 (UTC)

@Walter Görlitz: I don't know why you suggest that I have asked questions in an unrelated page: this is a very related page - and I asked no questions. It was Jc3s5h who asked a question, and it was on my talk page, which is why I am directing you there. This thread was not intended to be a discussion; it is a pointer to an ongoing discussion, see WP:TALKFORK. --Redrose64 🌹 (talk) 20:36, 3 July 2018 (UTC)

My error. @Jc3s5h: you should be asking your questions where the guideline exists, not in an unrelated page. Walter Görlitz (talk) 20:39, 3 July 2018 (UTC)

@Walter Görlitz: It is relatively normal, when a user makes an edit you don't understand, to ask them about it on their talk page. This page, part of the MOS, is not obviously applicable to talk pages in any case, so it is not clear why one would raise an issue here about edits to a talk page. — Carl (CBM · talk) 20:45, 3 July 2018 (UTC)

Yes it is. But this is where 1) you should be observing the MoS, which you did not and 2) should ask questions about it.

Of course, you could show that you're interested in working collaboratively and stop the disruptive behaviour by honouring the accessibility guideline going forward, or at least recanting or clarifying your comment about not being prepared to accept the guideline as stated on Redrose64's talk page. See WP:NOTHERE. Walter Görlitz (talk) 20:53, 3 July 2018 (UTC)

I really don't understand your comment. I wasn't the original editor, who has been on WP since 2009 and in my experience always seems to edit collaboratively. I simply pointed out that there is no reason to expect anyone to follow an MOS guideline on a talk page, because the MOS and this page in particular is explicitly about articles. Terminology such as "recanting" brings an unexpected connotation to the discussion, I think. — Carl (CBM · talk) 21:30, 3 July 2018 (UTC)

This is not about that talk page, but about the comment @Jc3s5h: left there. If Jc3s5h doesn't want to follow the guideline as stated here, Jc3s5h should feel free to state that. I will take that as a sign that Jc3s5h is WP:NOTHERE and take the discussion to WP:ANI. The community doesn't end at one talk page. Walter Görlitz (talk) 22:22, 3 July 2018 (UTC)

I take extreme exception that methods of communication can be suppressed because some people have difficulty perceiving the medium in which the communication is expressed. This guideline should make it clear that, while efforts should be made to make information accessible to as many as possible, the inability of some to easily perceive the information is not an excuse to suppress the information. As others have pointed out, this page is devoted to articles, so it doesn't apply to talk pages. But if it did, it would not be acceptable to limit all editors to one paragraph responses on the grounds that blank likes make the page less accessible to certain users. Jc3s5h (talk) 23:03, 3 July 2018 (UTC)

Taking a closer look at WP:LISTGAP within Wikipedia: Manual of Style/Accessibility, I see that, in effect, it contradicts the first sentence, "This is a guide to editing articles for accessibility." [Italics in original, bold added for emphasis.] The examples in WP:LISTGAP are of talk page dialogs, which are not articles and not real lists. Jc3s5h (talk) 23:14, 3 July 2018 (UTC)

(edit conflict) @Jc3s5h: In stating this you intentionally ignored LISTGAP again and I have corrected it. It seems to me that you have your own ideas about how to interact with the community. You realize how this looks to the community. I strongly advise you to reconsider and start working collaboratively and stop the disruptive behaviour. Walter Görlitz (talk) 23:15, 3 July 2018 (UTC)

I made my best effort to separate two paragraphs at the same level of indent (since the second paragraph was by the same editor, me, and not a reply to the first paragraph). I did not leave a blank line in the wikitext. And I prefer to recognize the portion of this guideline that says it is about editing articles, rather than the part that says it's discussing lists but uses talk page dialog as examples. — Preceding unsigned comment added by Jc3s5h (talk • contribs) 23:29, 3 July 2018 (UTC)

That's not what LISTGAP is about. Your first edit was the problem. The second was fine, but the paragraph mark-up was not needed. Walter Görlitz (talk) 23:48, 3 July 2018 (UTC)

Don't forget to sign your talk page edits. Walter Görlitz (talk) 23:48, 3 July 2018 (UTC)

And "<p/>" doesn't make any sense in the context anyway. Unless HTML5's details have changed yet again, that's not even valid markup.  — SMcCandlish ☏ ¢ 😼  03:03, 4 July 2018 (UTC)

• The logic problem in Jc3s5h's dismissive approach is that the issue has nothing to do with rule-thumping about what is or isn't a guideline or whether it is or isn't "officially" applicable only to articles. That's just wikilawyering. The point is that it's bad markup and makes things difficult for other people for no reason.

  If you want to do a separate paragraph in a list item on a talk page, you can just do, e.g., *Blah blah.<p>Yak yak.</p><p>Doodle doodle dee. ~~~~</p>. A templatey alternative is: *Blah blah.{{pb}}Yak yak.{{pb}}Doodle doodle dee. ~~~~. (If you do the manual-markup version, the closing tags are needed, or syntax highlighting on the page gets hosed, for anyone using the various syntax highlighting gadgets and scripts.) This isn't hard. I've been doing it for years.

  PS: "They're not real lists" is a non-argument. They're using real list markup, so it causes the same problem. HTML is not psychic and doesn't know if you are intending to create a list in the usual sense.

  PPS: See the wikisource of this post for how to use HTML comments to block out the material visually in the source code, too.
   — SMcCandlish ☏ ¢ 😼  02:56, 4 July 2018 (UTC) — My entire post is a single unbulleted-list item, including the block indentation.

Relative image sizing

Do we have a workable system for relative/flex image sizing (e.g. in %) instead of the dinosauric practice of giving fixed pixel widths? I would like to constrain the table column for images at List of cat breeds to, say, 10% of the table width and have images auto-fill that space. What I'm doing now is leaving them set at 100px and leaving the column with no set width but setting the rest to take up about 90 or 95% of the available width. But this is kind of crappy, given that screen resolutions widely vary; I would rather seem the pics a bit larger, depending on how big I make my viewport.  — SMcCandlish ☏ ¢ 😼  11:55, 14 July 2018 (UTC)

We've yet to come up with an ideal solution for image sizing (i.e., no matter what anybody supports, there will always be a "Yes, but" opposition to it). My "Yes, but" for what you seek is that it would ignore the image size user preference, which I consider important (it also has a hard-fought community consensus, btw). So I favor respect for the user size preference—although one of the "Yes, buts" is that it doesn't dynamically respond to changes in window size. Thus, |frameless|upright=0.45 or similar. Sorry this isn't the answer you want. ―Mandruss ☎ 12:19, 14 July 2018 (UTC)

That's about what I expected. I think we need to revisit this and soon, but it'll be a whole-WMF/MW-community thing, i.e. get the developers to implement something we can work with. This is just so 1997.  — SMcCandlish ☏ ¢ 😼  14:43, 14 July 2018 (UTC)

See also Wikipedia:Village pump (technical)#image widths that respond to page width. --Redrose64 🌹 (talk) 17:06, 14 July 2018 (UTC)

I was actually looking at the whatwg spec differences page from html 4 to 5 which indicated that % support in the img height and width attribute was remoced deliberately. --Izno (talk) 03:46, 15 July 2018 (UTC)

Yet another reason to ignore WHATWG and stick with the W3C specs which are developed by a real consortium that listens to the Web developer community, instead of written by a tiny handful of commercial interests who will basically never rethink a decision they pull out of their butts (and seemingly with the specific intent to spec-fork). Anyway, I would assume that em or some other relative means of sizing is available even in the WHATWG "standard".  — SMcCandlish ☏ ¢ 😼  16:47, 15 July 2018 (UTC)
Re-comment: If both W3C and WHATWG are going along with this, I have to retract that particular WHATWG criticism (though there's still no excuse for them spec-forking the meaning and permissible content of <cite>).  — SMcCandlish ☏ ¢ 😼  02:23, 16 July 2018 (UTC)

The W3C docs do indeed show that whilst HTML 4.01 allowed a percentage value to be given in the width= and height= attributes of the <img /> tag, HTML 5.0 (and subsequent releases) only allows a pure integer, which is assumed to be measured in px - for example width="100". But if the desired width is written as a CSS declaration, and put into the style= attribute of the <img /> tag, there is much more flexibility. All of these are valid: style="width:100px;" style="width:10em;" style="width:20%;" --Redrose64 🌹 (talk) 20:55, 15 July 2018 (UTC)

Glad the CSS approach will work in theory, though I'm guessing it won't "play nice" with WP at present due to all the back-end stuff MediaWiki does with images. Has anyone done any testing of this?  — SMcCandlish ☏ ¢ 😼  02:23, 16 July 2018 (UTC)

Not as far as I'm aware. We certainly can't test it on English Wikipedia, because the <img /> tag is not whitelisted: if I write <img src="//upload.wikimedia.org/wikipedia/en/a/a9/Example.jpg" style="width:5%;" /> it displays literally, not as an image. The only recognised way of displaying an image is with the [[File:Example.jpg|...]] syntax. This is converted by the MediaWiki software into an <img /> tag, but it is not possible to use such a tag directly.

If the MediaWiki software encounters something like [[File:Example.jpg|...]], and parses one of the parameters as a valid size, it will use that size to set the width= and height= attributes of the <img /> tag. For example, [[File:Example.jpg|100px]] will emit <img alt="Example.jpg" src="//upload.wikimedia.org/wikipedia/en/thumb/a/a9/Example.jpg/100px-Example.jpg" width="100" height="108"> plus a few other parameters. But if you try to use [[File:Example.jpg|5%]] that |5% is not interpreted as a size, nor as any of the other valid image syntax options, so it is treated as a caption, and you get <img alt="5%" src="//upload.wikimedia.org/wikipedia/en/a/a9/Example.jpg" width="275" height="297"> (plus a few others). --Redrose64 🌹 (talk) 08:19, 16 July 2018 (UTC)

The reason that % is not allowed for img attributes, is because the width and height attributes denote the intrinsic width. And if you use a percentage of an intrinsic width/height of an image, it means you need to load the image before you can determine the size that it needs to fill on the page. That would cause the page to reflow ('jump'), which is a performance problem. You can use percentages in width style attributes, because there width is relative to your parents' width. —TheDJ (talk • contribs) 09:20, 16 July 2018 (UTC)

I'll tell a little known secret... images in wikicode accept a class= parameter. And soon there will be TemplateStyles, you can use that to style images directly. See also the banner logo at the top of mw:Wikimedia_Hackathon_2018.

Note btw that tables are bad at dynamic sizing no matter what. A table sizes to it's content, and content therefore needs a minimum size (which is why on mobile images become 0px without setting a min-width on a column if the table is bigger than the screensize). A table will even expand beyond the available space (overflow) if content doesn't fit. That makes it opposite to almost all other behaviour of CSS/HTML. Tables are terrible for content which needs to be screensize agnostic really. —TheDJ (talk • contribs) 09:20, 16 July 2018 (UTC)

Template:IPA vowels

I've just found out about this blog post about reading IPA with screen readers, in which it is mentioned that the vowels chart at the International Phonetic Alphabet article is not accessible to screen readers because it does not show as a table. This is because it lacks headers and is therefore a layout table, which aren't displayed as tables by default in screen readers. The vowels chart is in the {{IPA vowels}} template, but {{IPA chart/table vowels}} isn't that much better, mostly because of the weird column layout. Theconsonant tables are fine. I don't even know where to start to fix the vowel tables/charts ... could somebody help out? I'm also cross-posting to Template talk:IPA vowels. Graham87 01:04, 16 July 2018 (UTC)

@Graham87: Neither is a table at all really. They are divs, where people have used all sorts of tricks to draw lines between. It's more of a graph really. Not sure of the best approach here really. —TheDJ (talk • contribs) 09:33, 16 July 2018 (UTC)

@Graham87: I've created a data table holding the same information at Template:IPA vowels/accessible. Would you have a look at it and see if it is more comfortable to read for you? --RexxS (talk) 10:42, 16 July 2018 (UTC)

@RexxS: Thanks, that's much easier to read here! I've let the author of the blog post know about this new version and invited them to comment here. Graham87 10:54, 16 July 2018 (UTC)

Is it possible to make screen readers interpret a table like Template:IPA vowels/accessible in lieu of the graph? Nardog (talk) 17:38, 16 July 2018 (UTC)

Hi, I'm the author of the blog post. What I did (linked to original, click on the accessible chart link to compare) was basically the same as the commenter above (I don't know how to link the comment) did. As for @Nardog:'s question, you can, with css and javascript. Add the attribute aria-hidden to the current chart, and position the other one outside the viewport (say, -10000px in any direction). But I understand this is really cunversome. Is there any reason why the current chart has to be preserved? Sukiletxe (talk) 19:42, 16 July 2018 (UTC)

@Sukiletx and Nardog: Yeah, I've heard bad things about that technique with Chrome (can't find the link at the moment). I agree that it shouldn't be used for a whole chart. Graham87 01:15, 17 July 2018 (UTC)

Ah found it, and it can affect any browser where CSS isn't loaded propery for some reason. Graham87 01:25, 17 July 2018 (UTC)

Pseudo-headings before lists

I prefer this version. Rexxs prefers that one, on the theory that "We shouldn't be offering pseudo-headings on a parity with genuine headings". But that's a bit of a straw man; I never suggested they're equivalent. Rather, the third (and second of the legit) examples is a special use case where the material needs to be set off from what comes before it but doesn't rise to the level of needing a section heading, e.g. because it's one of a series of a bunch of short lists all covered by a heading above it and which do not stand on their own. The overall point is to illustrate how to do an accessible pseudo-heading, because people will keep doing them and they will keep doing it by abusing MOS:DLIST markup unless we give them an alternative.  — SMcCandlish ☏ ¢ 😼  04:04, 2 August 2018 (UTC)

Our accessibility guidelines have excluded that example consistently over the years, and my revert of your over-bold addition attracted thanks from Pigsonthewing and Izno, so I'm clearly not the only one objecting. There's no strawman. The very act of offering an example right next to the example of a genuine heading with a nice green tick mark is clearly indicating an equivalence between genuine headings (resulting in <h2, 3, 4, etc.>) and some cobbled-up bolded and anchored pseudo-heading. Let me be clear about my objection: headings are the most important elements that a screen reader has to navigate around pages. An editor needs a very good reason indeed to use a pseudo-heading instead of a proper one, and pseudo-headings are very much a third-rate alternative – one should consider bolding as the "least bad of a bunch of bad alternatives". Special cases should remain "special", not given equal prominence with recommended techniques; and illustrating how to do a second-rate job becomes an open invitation for editors to do just that. I have no intention of arguing the toss about accessibility with every single editor who thinks that making text bold is just as good as a proper heading, and I have even less intention of handing them a weapon to justify their thoughtless practices. No alternatives. --RexxS (talk) 14:32, 2 August 2018 (UTC)

Your preference - or RexxS' - are immaterial. The WCAG accessibility guidelines tell us to mark up headings as such. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:14, 2 August 2018 (UTC)

That's fine, for things that are and should be headings at the document-structure and ToC level. What I'm getting at is cases that are not, where something looks "heading-ish" and is either being poorly marked up as a heading or even more poorly marked up as a broken d-list, when what the material is, clearly, is an introductory list caption. We have caption markup for tables and images, but not for lists, an oversight on the part of W3C and WHATWG. If you and Rexxs don't think this comes up enough to account for it here, I can live with that, but not doing so is going to increase the frequency with which people either wrongly use mangled list markup or wrongly mark as a heading something that is not, being told there is no third way, no way that actually corresponds to the semantics of the material.  — SMcCandlish ☏ ¢ 😼  00:33, 3 August 2018 (UTC)

For a screen reader "ToC level" is meaningless. Using a screen reader, a visually impaired visitor can from any point call up a list of headings – the real ones, not "heading-ish" shit – and go to whichever one they want.

There is no such thing as "poorly marked up as a heading". If it's semantically capable of being a heading, then marking it up as a heading is helpful and correct – not "poor" – markup.

There is no such thing as "an introductory list caption". The word you're looking for is "heading".

W3C and HTML have no caption markup for images. That's merely a compound element created for convenience by the MediaWiki software. A screen reader gives no more significance to our image captions that it does to any other piece of text inside a div.

Editors will always abuse markup because they don't know any better. We correct mistakes and try to educate; having straightforward guidance ("bad" vs "good") makes it easier to accomplish that.

I've yet to see an example of an editor "wrongly mark as a heading something that is not", so I'm not going to worry about that.

There is no "third way". All of the markup we're considering looks okay to a sighted visitor, so the main reason we're trying to be semantically accurate is to give screen readers a better experience. Marking up headers as headers is the best way of doing that. Marking up headers as something else provides diminished functionality and often considerable annoyance to the visually impaired. Your third way is very much a second-rate way of lessening the annoyance a little, but it's still sub-standard. We don't need examples of that for new editors to copy. --RexxS (talk) 11:28, 3 August 2018 (UTC)

W3C and HTML have no caption markup for images. <figcaption>. --Izno (talk) 12:14, 3 August 2018 (UTC)

Good point. Introduced in HTML5, but I can't see any way of using it in Wikipedia pages because of the lack of <img /> tag. I'll strike that anyway as inaccurate. --RexxS (talk) 12:52, 3 August 2018 (UTC)

Yeah, figcaption has a phabricator task that was waiting on shim support for legacy (coughIEcough) browsers. --Izno (talk) 12:56, 3 August 2018 (UTC)

This is largely just a pile of "I dogmatically refuse to absorb the meaning of your words" nonsense, so I'm just going to move on and will try again some other day people without a "there is no such thing" mindset want to have an actual discussion. There very, very obviously is such a thing as a caption that is not a heading; suggesting otherwise betrays an general ignorance of how to structure and present information.  — SMcCandlish ☏ ¢ 😼  15:55, 3 August 2018 (UTC)

No, it's actually a pile of "I know best and I refuse to accept that accessibility is important" on your part. When you try again some other day to give bad advice on accessibility, you'll meet the same response. There's no good alternative to marking up a heading as a heading. End of story. Table captions are indeed not headings, but they are the only captions that MediaWiki software implements. Of course an implementation of structured information should allow headings for any sort of data: any list can be re-written as a table with one column or row, when headers then become available, but HTML doesn't yet implement the concept of a list header (possibly apart from description lists). MediaWiki software certainly doesn't, so before you rudely start accusing other editors of ignorance, you should check your own understanding of the limits that the software we are working with imposes on us. --RexxS (talk) 10:14, 4 August 2018 (UTC)

On a related matter, see these edits at Wikipedia:Manual of Style/Dates and numbers between (on one side) BushelCandle (talk · contribs) and myself, and (on the other) EEng (talk · contribs) alone. Edits by two other people are not relevant. I did think of bringing it here at the time, but other matters (see e.g. its talk page) were occupying me. --Redrose64 🌹 (talk) 19:46, 3 August 2018 (UTC)

Template talk:Marriage#Green

Template:Marriage has a function where rolling over a year produces hovering text of a full date. This is deprecated by Wikipedia:Manual of Style/Accessibility#Text. How else could/should this information be presented? Please comment at the link above. DrKay (talk) 11:46, 15 August 2018 (UTC)

Question on subsections

Moved to Wikipedia talk:Manual of Style#Single subsections

I'm in a debate right now over what is classified as a "subsection". To my understanding, in order to classify information as a "Subsection" it requires a "subheading"...a level 3 heading. To them, they believe that based on what this page says, a subsection is any information under a section after another division has taken place. To illustrate:

==Release==
General release information.
===Marketing===
Specific marketing information.

To them, there are 2 subsections in this scenario, where as I would say there is 1 subsection and lead-in information from the main section header. The point of the argument boiling down to Chicago style and most others indicating that you can't have a single subsection. If you have 1 then you have to have 2. Since you all edit this page regularly, I figured I would determine if the people that edit the MOS for sectioning see that differentiation the same way...that one subheading creates 2 subsections by default, or if a subsection is indeed defined by having a subheading?  BIGNOLE  (Contact me) 13:50, 25 May 2018 (UTC)

From an accessibility point of view, it is the rendered html that is important, not the wiki-markup. Since every page has a title, and that title becomes the level 1 heading (rendered in html as <h1>...</h1>), every heading marked up on an article page is in fact a sub-heading, including the level 2 headings (rendered in html as <h2>...</h2>). If you define a subsection as the text associated with a sub-heading, as soon as you introduce a level two heading, you are creating a subsection. In that case, you can indeed have a single subsection (presumably you would have to call any text before that first level 2 heading the "main section"). I'm not sure that answers your question directly, but it's how I understand the situation. --RexxS (talk) 15:55, 25 May 2018 (UTC)

The opposing argument is that the text ahead of the level 3 heading is still level 3 information, just doesn't have a level 3 heading. Your understanding would imply (if I follow you correctly) that you see the information ahead of the first instance of a level 3 or level 2 heading as part of the main section, not part of a newly, unidentified subsection within that section?

To clarify, I get that technically a level 2 is in fact a subsection under a level one, but we're really talking about level 3 status. We ignore level 1, because that's simply the article title, and focus on what comes after. Yes, you could technically have a single subsection at level 2, but that likely wouldn't continue to be an article because it likely wouldn't meet the GNG if there was only 1 section of information. The argument I'm involved in seems to be two fold: Per writing rules, if you have a subsection identified you should have at least 2 (you can have more, but you shouldn't have just one). This isn't a Wikipedia HTML issue, this is writing structure. The second part is how one defines a "subsection". They want to argue that the information above a 1.1 header is still in fact a subsection of that section, without a 1.1 or 1.2 header attached to it.  BIGNOLE  (Contact me) 16:07, 25 May 2018 (UTC)

"Chicago style and most others indicating that you can't have a single subsection. If you have 1 then you have to have 2."

Let us all spend a moment considering what CMOS 17 1.56 actually says on this subject:

"...when a section of text is subdivided, there should ideally be at least two subsections (e.g., two or more A-level subheads in a chapter or two or more B-level subheads under an A-level subhead). Occasionally, however, a single subdivision may be called for—for example, to emphasize a unique case or a special consideration. A single subdivision may also be needed for specialized sections like chapter endnotes (see 1.62)."

So if this dispute is based on someone's belief that CMOS says a single subsection is always bad writing, then you can end the dispute now: CMOS does not actually say that. WhatamIdoing (talk) 18:16, 25 May 2018 (UTC)

That's for unique cases, just like there are unique times when a single sentence paragraph is warranted. Unique cases is not what's being argued. The individual is arguing that no reliable source indicates that you should have at least 2 subsections, and thus single subsections are not for "unique case", but just the way. Just like you cannot indefinitely write single sentence paragraphs, the general rule of thumb for CMOS and other writing styles is that you should have at least 2, as part of your exert indicates.

They are also arguing that subsections are not defined by having as subheading, which is what I was also looking for clarification on. There are two arguments happening. Whether there should generally be at least 2 subsections, and how a subsection is actually defined into existence.  BIGNOLE  (Contact me) 19:43, 25 May 2018 (UTC)

No, it's not just for unique cases. There are three cases specifically named in CMOS:

1. The single subsection describes a unique case (e.g., the section ==How to sell a screenplay== contains a subsection that describes the 'unique case' of selling a screenplay ===If you're already as famous as Steven Spielberg===).
2. The single subsection emphasizes a special consideration (e.g., ==Using sunscreen== followed by ===But don't put sunscreen on newborn babies===).
3. The single subsection contains specialized sections (e.g., endnotes).

Note that's three possible uses, and the first two could appear multiple times in a single paper/article/document. Also note that these are introduced in CMOS with the words "for example", which phrase means "This is not an exhaustive list of all the situations in which a single subsection might be considered the best possible arrangement of the material you're working on".

As for Wikipedia's terminology: A section is whatever material is after a ==Level 2 header==, until either the end of the page or the next Level 2 header. A subsection is similar anything below a ===Level 3 header===, or Level 4 or Level 5 headers. WhatamIdoing (talk) 23:24, 28 May 2018 (UTC)

Hunting around, I'm pretty sure that this thread has been started as a consequence of the ongoing discussion at Wikipedia talk:Manual of Style/Film#To be or not to be a subsection (from which I perceive that "them", "they", etc. mentioned here refers to Adamstom.97), so by also discussing the topic here, we're now in a WP:MULTI situation. Further, by not mentioning the Manual of Style/Film discussion here, or this discussion at Manual of Style/Film, this could be construed as WP:OTHERPARENT. --Redrose64 🌹 (talk) 07:14, 27 May 2018 (UTC)

Thanks for the ping Redrose64, I was unaware of this branch of the discussion. I personally would prefer if we kept it all at one place, but to respond to the specific points raised here I think from my perspective of this discussion I would like to know if there is any accessibility issues with having only a single subheading. Regardless of whether or not we should have a single subheading per any apparent writing laws, it would help to know whether we are currently causing any accessibility problems at the pages where we do only have a single subheading (for instance, is there a problem with the Writing, Casting, and Visual effects sub-sections at Production of Avengers: Infinity War and the untitled Avengers sequel, which are all currently used to collect together alike information that otherwise would be dispersed chronologically through the rest of the general content). - adamstom97 (talk) 08:02, 27 May 2018 (UTC)

@Adamstom.97: I can say with near-absolute certainty that having a single subheading in an article causes no accessibility problems, as long as it's a level 2 heading. Similarly, having a single level 3 heading is no problem as long as it follows a level 2 heading. And so on for a single level 4 heading following a level 3 heading, etc. The headings used in Production of Avengers: Infinity War and the untitled Avengers sequel cause no problem with accessibility (sadly, I can't say the same for the images). HTH --RexxS (talk) 19:32, 27 May 2018 (UTC)

Cool, thanks RexxS. In that case, I think we need to keep this discussion over at MOS:FILM from now. But just on your last note, can you elaborate on the problem with the images so we can get that sorted? - adamstom97 (talk) 00:24, 28 May 2018 (UTC)

@Adamstom.97: When someone using a screen reader encounters an image in an article, they will hear the alt text for the image if it has been supplied. That is an opportunity for us to give some of the information that a sighted person gets when they look at the image, and that helps make their experience of using Wikipedia better. There is a Manual of Style page at WP:ALT that goes into detail, but in simple terms you add alt= and a brief description to each image. For example, in Production of Avengers: Infinity War and the untitled Avengers sequel, you might add | alt=Dual image showing a man's face and its computer rendered version to the last image on the page File:Masquerade test.jpg. Remember that the next thing they hear will be the caption, so there's no need to repeat what's in that. In some cases the caption already gives all of the descriptive information available for the image, so there's not much point in adding alt text in those cases. Hope that helps. --RexxS (talk) 09:24, 28 May 2018 (UTC)

To be clear, I wasn't asking for input on the Deadpool discussion, which is why I didn't mention it. I asked for a definition of subsectioning. I explained how the question came about and it's turned into what specific instances a subsection can be single, but not what my original question was. I asked how a subsection is defined. The argument was whether information under a level 2 header is classified as "level 3" without a level 3 header. That's what Adam was arguing, that Information under level 2 headers and information under section 2.1 headers (aka level 3 headers) are the same level of information. I have said that it isn't, those are two different levels (which is the basis of the other argument, but not what I came here for).  BIGNOLE  (Contact me) 14:09, 30 May 2018 (UTC)

Text in paragraphs does not have "levels". Levels are a property of headings, and there are six ranging from level 1 (the <h1>...</h1> element, which we use for a page title) to level 6 (the <h6>...</h6> element, which we markup with six opening equals signs and six closing). Anything that happens between e.g. a </h2> tag and a subsequent <h3> tag is nothing to do with the heading, so doesn't have a level.

The HTML 5 specification provides the <section>...</section> element to structure page text hierarchically, but the MediaWiki software uses these tags for a different purpose. --Redrose64 🌹 (talk) 10:38, 31 May 2018 (UTC)

I get that. That was my argument. That is the only reason I brought up the details of the argument regarding more than 1 subsection (aka level 3 and below), as the counter argument was that the text between a Level 2 heading and a Level 3 heading was in fact the same level of information as was under the Level 3 (just simply without a level 3 heading). As such, they believe that created 2 "subsections" by default, just one without a level 3 heading. My detailing the argument wasn't meant to do anything but provide clarification so as to attain a more concrete definition of "subsections" to point to, as Adam did not believe that was the case (not to circumvent a discussion about whether to have more than 1 subsection, as I wasn't looking for input on that).  BIGNOLE  (Contact me) 13:34, 31 May 2018 (UTC)

Notices

For anyone still interested in this discussion, a new one following on from these issues has been started at Wikipedia talk:Manual of Style#Single subsections. - adamstom97 (talk) 08:47, 1 July 2018 (UTC)

For those watching this page, I have now started an RfC on this issue as it has still not been resolved. You can find it at Wikipedia talk:Manual of Style#RfC on single subsections if you wish to participate. - adamstom97 (talk) 00:19, 26 August 2018 (UTC)

Use of Angle Brackets for orthography in lingusitics related articles

There is a template to enclose text in angle brackets.

This is used, for example, here:

This usage is described on the wikipedia page for angle brackets:

In linguistics, chevrons indicate graphemes (i.e., written letters) or orthography, as in "The English word /kæt/ is spelled ⟨cat⟩."

If this usage is considered standard across wikipedia, should it be included in the manual of style? Or is this usage too discipline specific to be included in the general manual of style? --Tomatoswoop (talk) 16:10, 9 September 2018 (UTC)

Page hiding nearly all its content

FYI

 – Pointer to relevant discussion elsewhere.

Please see Talk:List of Advanced Dungeons & Dragons 2nd edition monsters#Remove forced-collapse content boxing.

I didn't just strip the markup, since it's probably preferable to have a consensus-record discussion in the page history, to forestall someone trying to do that again.  — SMcCandlish ☏ ¢ 😼  15:03, 17 November 2018 (UTC)

Contrast between visited & unvisited links

Please see Contrast between visited & unvisited links. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:07, 30 November 2018 (UTC)

Font sizes in infoboxes

Is this guideline actually supposed to prohibit using <small></small> tags inside infoboxes? Because if so, it seems completely out of step with the usual practice (i.e. long-standing consensus), and eliminates an extremely useful tool for the majority of readers to (in theory) help a tiny minority. Modernponderer (talk) 20:57, 10 December 2018 (UTC)

As per my understanding you are mostly correct: "In no case should the resulting font size drop below 85% of the page's default font size (i.e. 11.9 px in Vector skin or 10.8 px in Monobook)."

It is a minority, but not a tiny minority. It's those who have visual impairments.

It's not a theory, there are several accessibility guidelines mandated by governments around the world to help accommodate people with disability.

It's also not usual practice as I've been removing it wherever I see it for about two years, and other editors have started following suit. Walter Görlitz (talk) 00:32, 11 December 2018 (UTC)

I'm curious why referring to people with certain visual disabilities as "a tiny minority" is meant to carry any weight whatsoever? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 01:27, 11 December 2018 (UTC)

And I'm curious why anybody would describe the practice of reducing the font-size below the already-reduced size in infoboxes as "an extremely useful tool" for anybody, let alone the majority of readers. It's a worthless piece of affectation that serves no useful purpose at all and merely inconveniences vast numbers of elderly visitors and others with impaired vision. The real long-standing consensus is encapsulated in the guideline. --RexxS (talk) 01:58, 11 December 2018 (UTC)

For the record, I personally uphold the vast majority of the accessibility guidelines well beyond mere adherence to policy, not just to help people with disabilities but also because they essentially force an overall higher standard of coding on Wikipedia that is useful for many general applications. I often go out of my way to clean up articles for accessibility purposes, especially where it is obvious no other regular contributors are going to do it any time soon.

Having said that, this specific aspect of the guideline is completely disconnected from reality in my view. One problem is that infoboxes have very limited space by their very nature. They are essentially fixed horizontally, since the article must have the bulk of the space, so they are already forced to stretch down to ridiculous vertical lengths (that often have negative consequences for paragraphs and images).

The traditional use of these tags in infoboxes, as done on Wikipedia for years before anyone really started discussing this, has been to indicate supplementary information that is nonetheless necessary for context. Now, accessibility-conforming editors are faced with a dilemma: either simply remove the tags, thus making the infoboxes even larger and simultaneously diverting attention spans away from the most important content in them; or, remove the text in question entirely, which is often not even permissible for content reasons but nevertheless still done sometimes. (Of course, there are other options such as using footnotes, but nobody really does that because it quickly turns into a mess that nobody wants to use – and I'm pretty sure these come with their own accessibility issues in any case.)

In short, this issue is a zero-sum game in which the vast majority of Wikipedia readers are losing out. I cannot personally support that, and more importantly I have serious doubts it would pass a community-wide RfC (as opposed to one done on this page for example). Modernponderer (talk) 02:35, 11 December 2018 (UTC)

Again, some bad assumptions. There is no limitation to the width of an infobox. Also, infoboxes are supposed to convey only key information from the article. They do not need to convey all information from the article. If something is better left explained in the prose of the article, that should be done. Whether to actually include that information is at the discretion of the editor.

What it seems to me we're really accommodating is poor editing style and ignorance of this MoS. It would be better to inform editors on WP:COMMONALITY instead. Yes, COMMONALITY is about language WP:LANGVAR, but in this case applies to acceptance that there are different abilities that, in most cases, are the not fault of the person who must be accommodated. Walter Görlitz (talk) 03:16, 11 December 2018 (UTC)

(edit conflict) @Modernponderer: On the contrary, the arguments adduced for using smaller text in infoboxes fly in the face of our primary advice on infoboxes: namely that they should contain only key information, and even then only information that can be delivered succinctly and concisely. There is no place for supplementary information: it would either be unnecessary and a distraction from the genuinely important information, or it would indicate that the information is nuanced and unclear to the extent that has no place in the infobox, but should be expanded on in the main text, where there is space for it. If you are producing infoboxes that are so stuffed full that the text cannot be comfortably fitted without recourse to shrinking text below the size that many visitors cannot read, then you are clearly trying to put too much information into that infobox.

If you intend to reject 85%, then you need to consider where you are prepared to draw the line? Would you find text acceptable at 75%? at 67%? at 50%? Don't you accept that there has to be a lower limit? because if not, let's just reduce the text-size in infoboxes to 10% and then you can pack in as much information as you want, even though nobody can read it.

Once you've conceded there has to be a lower limit, you'll have to accept that a value which everybody who took part in the original debate on the issue agreed could be comfortably read is as good a candidate for that lower limit as you're likely to get consensus for.

So go ahead and waste your time on an RfC, because those are the arguments you'll have marshalled against you, and I'll tell you now, I have no doubt whatsoever that the community will reaffirm their support for the sensible limit that this guideline has agreed. --RexxS (talk) 03:24, 11 December 2018 (UTC)

To be clear, I do not care about the actual percentage sizes. What I am looking for is simply two different sizes of text for use in infoboxes: one for normal text with the most important information, and a smaller one for any necessary context. Right now, this guideline essentially forces all text in an infobox to be the same size, which is not right.

And I am referring first and foremost to those cases where the supplementary information is essential to understanding. As a very common example, say a single TV series has had two seasons but with very different crews working on them. The information in the TV show's infobox template would be misleading without season qualifiers added – but without any smaller font size option, these make the infobox ridiculously large. And though one could theoretically use footnotes in this case, I would argue that even if they didn't make a mess of things the bigger problem is that "nobody" reads those, so again the necessary context is simply lost for the average reader. Modernponderer (talk) 14:38, 11 December 2018 (UTC)

To be just as clear, you need to care about percentage size, because that's caring for others, especially for some of our disadvantaged readers. You can't have smaller font-size in an infobox because many folks can't read it without difficulty or at all – and that is beyond dispute. The sensible decision has already been made to reduce the font-size in an infobox almost to the smallest that can be comfortably read by a wide range of readers, in the interests of keeping down the size of the box. You can have text that is larger in infoboxes, but not smaller. What certainly is not right is to cause difficulties for disadvantaged readers, just to please an editor's misguided sense of aesthetics.

Some tv show info

More tv show info

Yet more tv show info

A much, much longer piece of tv show info

This is a ridiculously easy way to add extra information to infobox fields without making it "ridiculously large", but you already knew that. Other techniques include using abbreviations with a key, such as (S1) = Season 1 or the template {{abbr}} to produce (S1) and so on. There is never any need to reduce font-sizes below what can be comfortably read, and infoboxes that are attempting to cram excessive information into them should be re-thought. That's not what infoboxes are for. --RexxS (talk) 15:37, 11 December 2018 (UTC)

Well yes, that's exactly what I was thinking of when I mentioned footnotes – I appreciate the visual example I guess (though not the disparaging tone used alongside it). But like I said: it looks pretty awful, and does not provide the necessary context at a glance – which for many readers is equivalent to not at all.

(And ironically, the superscript citation font itself technically violates this guideline, does it not? Especially in this case, where it is not just used for an unimportant number, but also a group specified by a letter.) Modernponderer (talk) 18:42, 11 December 2018 (UTC)

The crew is not vital to understanding the subject, and crew per season is even less vital. Save it for a thorough (and referenced) discussion in the article itself. So for instance, the executive producers listed at Friends could easily be trimmed. Similarly, running time should convey the standard running time, not that used in a handful of foreign markets for a select number of episodes. Finally, small is not needed for the picture and audio format parameters. Walter Görlitz (talk) 22:12, 11 December 2018 (UTC)

@Modernponderer: The visual example is a result of the need to demonstrate how simple it is to avoid lengthy "supplemental" information, which of course is not necessary. The disparaging tone is a result of my distaste for the lack of concern expressed for folks like myself who can no longer read tiny text. So I'm afraid you'll have to bear with me on that one.

As I said, your "looks pretty awful" is an aesthetic judgement that I don't share. I'm just grateful that I can read it – and that's not a judgement, it's a fact. It does provide all of the information, although not at-a-glance. However, the superscript doesn't need to be read, it just needs to be clicked. A single click will take you to the readable text, and a back-click will return you to the same place in the infobox. The group refs, of course, allow the group references to be placed immediately below the infobox if desired. --RexxS (talk) 01:22, 12 December 2018 (UTC)

Request for comment on Template:Infobox broadcast

Moved from Template talk:Infobox broadcast § Request for comment on broadcast infobox format

 – by Mvcg66b3r (talk) 23:28, 1 January 2019 (UTC)

Moved to Template talk:Infobox broadcast § Request for comment on Template:Infobox broadcast

 – by Mvcg66b3r (talk) 02:00, 2 January 2019 (UTC)

Vertical alignment in tables

Hello, I started a discussion at WT:MOSTABLE regarding vertical alignment in tables and if using "top" instead of the default of "middle" is problematic or not. Editors are invited to weigh in there: Wikipedia talk:Manual of Style/Tables#Vertical alignment. Erik (talk | contrib) ^{(ping me)} 20:28, 7 January 2019 (UTC)

Use of the hr element in a table

Is a use of an <hr /> to visually divide a column in a table like in this example correct? Does it violate accessibility? --Gonnym (talk) 19:42, 7 January 2019 (UTC)

As long as whoever uses that technique understands that a screen reader will effectively ignore the horizontal rule and will read out the entire contents of that table cell as if the rule wasn't there, then there should be no problem that I can foresee. --RexxS (talk) 21:51, 7 January 2019 (UTC)

Ok, thanks RexxS for the fast answer! --Gonnym (talk) 22:00, 7 January 2019 (UTC)

I'm not entirely sure it meets the intent of the specification, but that's just an 'I'm not sure' and a "clearly does not". When inside tables, I'm usually inclined more toward having a separate cell for the other material and to rowspan the header cell. (Which may [not] be desirable as the far right cell here would also need to be spanned--a trivial fix to move that date left, and TBH that date should be on the left rather than the right.) --Izno (talk) 22:36, 7 January 2019 (UTC)

Infobox caption/header discussion

FYI

 – Pointer to relevant discussion elsewhere.

Please see Template talk:Infobox#Standardisation of heading?. --Redrose64 🌹 (talk) 23:06, 16 January 2019 (UTC)

Infoboxes: listing multiple entries in a single field

FYI

 – Pointer to relevant discussion elsewhere.

There's a discussion at Wikipedia talk:WikiProject Infoboxes#Listing multiple entries in a single field where accessibility has been mentioned. --Redrose64 🌹 (talk) 16:50, 18 January 2019 (UTC)

Responsive design at Wikivoyage

Some of you may want to look at the progress being made at voy:Wikivoyage:Travellers' pub#Responsive design. WhatamIdoing (talk) 22:19, 18 February 2019 (UTC)

Accessibility disagreement

I've made a change to Module talk:Episode list to better comply with accessibility concerns in tables like the one in this example (the sandbox version is the newer one). An editor has commented out this part out of the documentation, stating that I don't have consensus on those local articles for that change, even though this page states that The WMF asserts that its policies "may not be circumvented, eroded, or ignored by Wikimedia Foundation officers or staff nor local policies of any Wikimedia project. See discussion here. I've tried following the guidance on this and other accessibility pages and would appreciate if other editors can contribute to that discussion. --Gonnym (talk) 01:03, 5 February 2019 (UTC)

Are you saying that I am deliberately discriminating against a specific group of people? In the same fashion that your quoted text bans racism, sexism, disablism, etc.? Is that what I am being compared to? -- /Alex/₂₁ 02:34, 5 February 2019 (UTC)

Anyone who knowingly ignores the guidance at Wikipedia:Manual of Style/Accessibility #Tables is deliberately making the reading experience worse for anyone using assistive technology. Visually impaired readers have a disability that already makes reading websites more difficult, and MOS:ACCESS attempts to lessen that difficulty as far as possible. That means that the guidance here is not optional at an editor's whim, and there is already precedent for enforcing the site-wide consensus behind that guidance. It is true that WMF insists that its accessibility policy supersedes local policy, but in this case, there is full alignment with MOS:ACCESS, and the issue does not arise. --RexxS (talk) 17:17, 5 February 2019 (UTC)

Except that MOS:ACCESS isn't a policy. "This guideline is a part of the English Wikipedia's Manual of Style. It is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply." -- /Alex/₂₁ 22:31, 5 February 2019 (UTC)

You're going to have to learn that guidelines have just the same site-wide consensus as policies and are enforced just as strongly. You don't get to ignore them just because you feel like it. --RexxS (talk) 23:09, 5 February 2019 (UTC)

They are not. I can show you entire projects that ignore ACCESS and get away with it. Walter Görlitz (talk) 23:27, 5 February 2019 (UTC)

Yes they are, and just because some projects are ignorant of the problems they cause for users of assistive technology, it doesn't give carte blanche for those who know better. --RexxS (talk) 23:40, 5 February 2019 (UTC)

Different point entirely, but I understand what you're saying and it's related to WP:OSE. Walter Görlitz (talk) 23:41, 5 February 2019 (UTC)

"It is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply." I do know of a better policy. -- /Alex/₂₁ 23:43, 5 February 2019 (UTC)

Editors should indeed attempt to follow the Manual of Style, and occasional exceptions will apply. However there's no reason for making an exception when it worsens the reading experience for disadvantaged visitors, particularly when you know how to make the required improvements. IAR exists to improve the encyclopedia, and when you invoke it, you'd better be able to prove that you're improving an article. You'll find it's not a free pass to treat our disadvantaged visitors badly, just because you want to do things your way. --RexxS (talk) 01:28, 6 February 2019 (UTC)

They should, yes. However, there's no reason to change what is stable and already agreed upon, where the disagreement lies with only one or two editors, that have provided nothing to back up their claims, and thus I quote IAR because the current layout does improve the site by being the stable version, with no agreement to change. -- /Alex/₂₁ 01:35, 6 February 2019 (UTC)

WP:NOTIAR. Accessibility guidelines are not something that you can opt out of. Alex 21, I see that you're from South Australia; I suggest that you take a trip over to Perth, WA - with a view to meeting Graham87 (talk · contribs), one of our long-term prolific contributors (14 years, 221,081 edits) for whom accessibility issues are a huge deal. --Redrose64 🌹 (talk) 20:31, 6 February 2019 (UTC)

Lets try and go about this a different way Alex, could you explain what your issues with the proposed change are? --Gonnym (talk) 20:35, 6 February 2019 (UTC)

I see no reason for the proposed change. -- /Alex/₂₁ 00:04, 7 February 2019 (UTC)

This sort of table structure is so 2006. Also, Adelaide and Perth are pretty far apart. Graham87 05:16, 7 February 2019 (UTC)

@Alex 21: The reason that those tables need to be changed is that they fall below the minimum standard for what is acceptable accessibility for a Wikipedia article. I'm disappointed that you "can't see" that, despite having had explained to you at Module talk:Episode list #Sandbox version update the problems it causes for anyone using a screen reader.

If you look at Doctor Who (season 3) #Serials as an example, you find a table that makes it impossible for anyone using a screen reader to read across a row to hear: "Story: 18, Serial: 1, Title: Air Lock, Directed by: Derek Martinus and Mervyn Pinfield, Written by: William Emms, Original air date: 25 September 1965, Production code: T, UK viewers (millions): 11.3, Appreciation Index: 54." For each of the Title, Original air date, UK viewers and Appreciation Index columns they will hear all 4 or 5 items together.

At the very minimum the table should have this sort of structure:

Story	Serial	Title	Directed by	Written by	Original air date	Prod. code	UK viewers (millions)	AI
18	1	Galaxy 4	Derek Martinus and Mervyn Pinfield	William Emms		T
		"Four Hundred Dawns"†			11 September 1965		9.0	56
		"Trap of Steel"†			18 September 1965		9.5	55
		"The Exploding Planet"†			25 September 1965		11.3	54
		"Air Lock"			2 October 1965		9.9	53
Two ships have crashed after a space battle, but the planet they have landed on is about to be destroyed. The beautiful female Drahvins seem friendly, but in fact it is the ugly Rills that are more tolerant and forgiving.

References

That would allow each episode's information to be read independently by modern assistive technology. Those tables need to be upgraded, and there's the result required as a minimum. I suggest that if the template/module approach is not amenable to improvement, then that should be scrapped and the tables replaced by ordinary, accessible wiki-tables as a matter of priority. --RexxS (talk) 18:45, 7 February 2019 (UTC)

Replaced by ordinary wiki-tables? I predict quite an opposition to that. However, since there will likely not be a case where no change occurs at all, I can at least see that the proposed table above could be beneficial. I recommend that the module be updated to be able to reflect such a change. -- /Alex/₂₁ 23:43, 7 February 2019 (UTC)

After tweaking the module code, the closest I have gotten (so far) are the tables at User:Alex 21/sandbox2 (at User:Alex 21/sandboxM, the first is the live module, the third is the layout which you gave in your example above). -- /Alex/₂₁ 13:49, 8 February 2019 (UTC)

Why are you using a colspan for the arc title and not a normal column? You wouldn't colspan the story number or the serial number, so why this? --Gonnym (talk) 15:30, 8 February 2019 (UTC)

Easiest way, and matches the given example above without having unnecessary empty columns. I say easiest way, in that if you want to tweak the code further so that RTitle prints on the same row as the first set of data, you can. If you're asking why RTitle isn't in its own column, to the left of the Aux titles, that's because it's simply unnecessary; all title data should exist in the same column. And if you continue to disagree with the use of rowspans in the table, then I must continue to disagree with any further changes that will span article's episode table and make it effectively unreadable. -- /Alex/₂₁ 15:45, 8 February 2019 (UTC)

Why should the data exist in the same column? It isn't the same data (unless I'm missing something). Isn't the first title the title of the arc, while the other titles the titles of the actual serials? If that is the case, then it should be in its own column. Regarding the rowspans in the middle - Looking at Wikipedia talk:WikiProject Accessibility/Archive 6#Row spans in tables and Talk:Sabrina Carpenter discography#WP:ACCESSIBILITY violations as two examples of recent discussions on this matter - has this stopped being an accessibility issue since then? If this isn't an issue, then I'm not objecting to rowspans and only have a problem with the way you handled the arc title. --Gonnym (talk) 15:58, 8 February 2019 (UTC)

The italicized title is the title of the serial. The quoted titles are the titles of the episode that make up the serial. They are all information related to the title, and hence belong in the column titled "Title". As the editor who's talk page you went to stated, there is no guideline or policy that dictates that rowspans cannot be used. Using them violates no written rule. As I stated: if you want to tweak the code further so that RTitle prints on the same row as the first set of data and in the Title column, you can. -- /Alex/₂₁ 16:07, 8 February 2019 (UTC)

Those are two different titles. Its like saying the episode number is information related to the title so it should be in the same column. All the information in a single row is information that is related to each other, that is why it is a row. Also, you are wrong, there is a policy, its the WMF non discrimination policy, and if rowspans are an issue, its part of the policy, regardless if it is (unfortunately) not written in this guideline. However, as I said, I don't know if it is still an issue and would appreciate if one of the more knowledgeable members here can add input on the matter. --Gonnym (talk) 16:20, 8 February 2019 (UTC)

Drawing straws. How is the episode number information related to the title? It is not. How is a title related to a title? It is a title. And there is still no written rule about the rowspans, so it cannot be part of the WMF non-discrimination policy. I could list down every issue I've had with Wikipedia and quote is as part of the WMF non-discrimination policy, but alas, none of them are written down in the guideline (guideline, not policy). If you want further opinions on this discussion, go ahead and post to a neutral location; do you plan to post to the talk pages of anymore particular editors? However, just as you decided to implement your edits into the module, I will be focusing on doing the same. -- /Alex/₂₁ 00:19, 9 February 2019 (UTC)

If rowspans mid-table are an issue (answer pending, by the looks of the above), why not just keep all rowspanned columns on the left of the table if that is more beneficial for screen readers? I.e. Story, serial, production code, title, written by, directed by all rowspanned (only prod code would have to move from the current set-up), followed by the individual episode titles (a column that could be omitted after that practice is dropped), air dates, viewers, AI? I don't see any good reason for the overall serial titles to be in the same column as the individual episode titles, especially considering the accessibility issue. U-Mos (talk) 02:08, 10 February 2019 (UTC)

To not spam the table with the same information on every single row, and because that would be a non-standard layout for those articles. Can you cite me an example of a live table, currently with the order story, serial, production code, title, written by, directed by? Why would we have the serial title on the left side, and then the individual episode titles on the other side of the table? What a mess! I see you refer to them as "serial titles" and "episode titles"; nice to agree that both sets are all titles. I also still see no discernible guideline or policy stating that rowspans are an accessibility issue, just heresay. -- /Alex/₂₁ 06:52, 10 February 2019 (UTC)

Please remember to remain WP:CIVIL. Per above, my suggestion is to avoid repeated information on each row (via rowspans), which I agree is desirable, while still remaining accessible to screen readers, which is essential. I don't agree that serial title, writer, director, episode title is an illogical order; those rowspanned evidently concern the whole serial, and those not have separate information for each episode. I'm not aware of any tables currently using that format, but then I'm not aware of any tables arranged by story rather than episodes either - and as that is unquestionably appropriate here, other aspects may need to be different too. I'm sure an answer to how screen readers tackle rowspans mid-table can be found, which I'll leave to Gonnym as I would not know the best place/person to ask. U-Mos (talk) 09:24, 10 February 2019 (UTC)

I certainly am remaining civil. Calling it a mess is not breaking that, it's just you disagreeing with it. Yes, it avoids the repeated information, while making a mess out of it. You might not agree that it is, but the two table and list templates have set up a clear standard on the order in the television community; why break what isn't broken? Doctor Who is part of the television community, is it not? Yes, the separate titles is a new factor, but we shouldn't be re-arranging the whole table for the cause of one column. If there's no written guideline or policy stating that rowspans are an accessibility issue, then there is no need to rearrange the whole table when a perfectly acceptable alternate suggestion has been given. -- /Alex/₂₁ 10:12, 10 February 2019 (UTC)

Have you ever heard of WCAG? The G stands for "guidelines"; but they're pretty much mandatory for websites that claim to be accessible (some countries have laws that enforce these guidelines). The relevant one here is Guideline 1.3 Adaptable, particularly 1.3.1 and 1.3.2. To save you looking them up, Level A is a "must"; level AA is a "should"; and level AAA is a "may". --Redrose64 🌹 (talk) 18:34, 10 February 2019 (UTC)

That's nice and all, but I can't find anything to do on that link with either Wikipedia, rows, spans, or rowspans in the middle of tables, nor do I see anything in that link that supports the fact that the most recent example given is a violation. -- /Alex/₂₁ 01:11, 11 February 2019 (UTC)

Why on earth should it mention Wikipedia?

Why can you not accept that the advice of experts in the field is something that ought to be respected? Just because you cannot see a problem does not mean that no problem exists. Or are you deliberately being difficult? I suggest that you install some screen-reader software, put on a blindfold, and then try finding your way around tables whilst they're read out to you. --Redrose64 🌹 (talk) 19:37, 11 February 2019 (UTC)

I already accepted the advice given, proposed a coded solution based off of the example given in this very section, then was told that I was wrong. Try again. -- /Alex/₂₁ 05:16, 12 February 2019 (UTC)

Realising that there's free extensions that can test screen reading (isn't the modern age wonderful?), I gave it a quick go. And yes, rowspanned cells were only read once on the first read across. I therefore continue to think that something like the following is the best solution:

Story	Serial	Prod. code	Serial	Directed by	Written by	Episodes	Original air date	UK viewers (millions)	AI
18	1	T	Galaxy 4	Derek Martinus and Mervyn Pinfield	William Emms	"Four Hundred Dawns"†	11 September 1965	9.0	56
						"Trap of Steel"†	18 September 1965	9.5	55
						"The Exploding Planet"†	25 September 1965	11.3	54
						"Air Lock"	2 October 1965	9.9	53
Two ships have crashed after a space battle, but the planet they have landed on is about to be destroyed. The beautiful female Drahvins seem friendly, but in fact it is the ugly Rills that are more tolerant and forgiving.

Seems to me the best fit between achieving accessibility and avoiding repeated/empty cells. U-Mos (talk) 10:30, 12 February 2019 (UTC)

If repeated cells are unwanted, I have no objection to this table layout. --Gonnym (talk) 10:53, 12 February 2019 (UTC)

Terrible. A mess. Zero need to separate titles and move the production code across. Production codes are now more important than the titles and credits of a series, to be listed first? This just creates more hassle, given that another module will need modifying to support one series. RexxS has already given a perfectly acceptable example. -- /Alex/₂₁ 13:38, 12 February 2019 (UTC)

If the production code is the only real issue here and if you don't mind that single cell being repeated, then that can easily be fixed. Also, please stop speaking in absolutes, and instead state your personal preference. Some of us see a need to separate titles, as 4 are episode titles and one is a story title. You obviously, don't want to separate them, which is your right, but for others, such as myself and U-Mos, it seems better. --Gonnym (talk) 13:59, 12 February 2019 (UTC)

I already have stated my personal preference, and the code and example for it exists, as previously linked. The issue is the complete and unnecessary rearranging columns, which will force yet another module to be tweak, all for one programme. They are all titles. They have stood as combined titles thus far for years. If one is a title, and the others are titles, then they belong in a column titled "Title". -- /Alex/₂₁ 14:05, 12 February 2019 (UTC)

Follows WP:ACCESS properly, unlike the example above, so ↑ THIS. (Side question – Is that even a "valid" prod. code? IOW, is the "prod. code" column even needed here?...) --IJBall (contribs • talk) 13:46, 12 February 2019 (UTC)

Can you quote what part of WP:ACCESS the example above violates? I've been asking this multiple times, and never got a straight answer. And yes, production codes such as these form an important part of Doctor Who. -- /Alex/₂₁ 13:49, 12 February 2019 (UTC)

WP:ACCESS refers to Wikipedia:Manual of Style/Accessibility/Data tables tutorial – within the latter you find the following: "They explain the data structure to inform navigation in a screen reader, especially to somewhat offset the accessibility problems associated with nested tables and with rowspan and colspan,[5] if these are used despite the accessibility problems they pose." This falls under the whole idea of properly doing "nested tables" – basically, if rowspan is to be used in a way that is compliant with WP:ACCESS, then it can be used on the left-side of a table, but then has to be used in progressively smaller increments as you go to the right. The example table directly above follows this... I've had many discussions with different editors over the years about this, and this is the only way to render tables intelligibly for people who use text-to-speech readers to read Wikipedia. As we can't just ignore this segment of our readership, as per Wikipedia:Non-discrimination policy, this is the way tables need to be done. This is especially true over competing versions that basically are simply a WP:ILIKEIT kind of thing. Bottom line: There's no compelling reason not to just follow WP:ACCESS in this case. P.S. Example #1 at User:Alex_21/sandboxM is also an acceptable variation on this, if people feel it's important to have the episode titles further to the left of the table... --IJBall (contribs • talk) 14:07, 12 February 2019 (UTC)

I'm still not seeing any content supporting the use of rowspans only the left side of a table. This is all well and good, but there is still nothing banning the use of rowspans; it sums up to what appears to be personal distate for the idea. Therefore, WP:ACCESS still does not support it. The live example of the template (after Gonnym's undiscussed changes to Module:Episode list) is a semi-decent example, except for the fact that it still separates titles, and unnecessarily duplicates information. -- /Alex/₂₁ 14:12, 12 February 2019 (UTC)

You saying it doesn't make it so. Several different editors have now tried to explain this to you, and your ignoring it for your "preferred version" (which only you seem to prefer) will not lead to a permanent solution here... --IJBall (contribs • talk) 14:19, 12 February 2019 (UTC)

Nor do other users saying the opposite make it so. There's still no support that rowspans are banned and not allowed. I put across a version based on the example given by another user, so that automatically makes the "only you seem to prefer" statement false. I see no solid reason for the modification of two high-use modules for the use of one programme. Single-use templates are often deleted; why should this single-use change be required? -- /Alex/₂₁ 14:22, 12 February 2019 (UTC)

Now that's a new kind of reaching. Single-use templates are discouraged because they can be replaced by the same text inside the article. This code has use in 28 different tables and much more invoking rows, not really a single-use by any sort of counting method I know. --Gonnym (talk) 14:32, 12 February 2019 (UTC)

I could name a multitude of templates that were used in dozens of articles, and deleted for having such little use. I see no solid reason for the modification of two high-use modules for the use of one programme. 28 articles out of 17,794 is a tenth of a percent - exceptionally minimal, to say the least. -- /Alex/₂₁ 14:34, 12 February 2019 (UTC)

Arbitrary break

Not fond of the sarcasm here and I will state that using one screen reader may not be a representative example of all screen readers. When I was testing for accessibility, I used three different readers and they behaved differently. Unless your reader comprises more than 80% of all readers used, it should offer information for us to improve layout but should not become a standard for us to follow. Walter Görlitz (talk) 16:12, 12 February 2019 (UTC) Walter Görlitz (talk) 16:12, 12 February 2019 (UTC)

Agreed. A sample is not a population. -- /Alex/₂₁ 16:34, 12 February 2019 (UTC)

Absolutely, I made a quick experiment and a suggestion from that but do not claim to be an expert on accessibility in any way. Happy to hear from those that are. Nor am I an expert in modules, and can't really comment on the number of uses without knowing the precedents - though worth Alex 21 noting that Doctor Who episodes have far more significant uses than Inhumans IMAX episodes, so why the complete opposite position here? However, unless I've misunderstood the inadequcy of putting serial and episode titles in the same column is pretty WP:COMMONSENSE, as screen readers surely won't be able to tell which is which? U-Mos (talk) 18:21, 12 February 2019 (UTC)

For those who are not aware, in the original "Classic series" 1963-1989 run of Doctor Who each season was subdivided into four or more serials, each serial being given both a title and a production code. These production codes were initially alphabetic, becoming alphanumeric in late 1974; they started at A and finished at 7Q. All bar one of these serials were further subdivided into anything from two to twelve episodes, and until mid-1966 each episode had its own individual title as well. Many books about the programme list the serial titles, episode titles (where applicable) and also the production codes. In most cases, each serial would have a single writer, and a single director would handle all episodes of a serial. See also WP:WHO/MOS#Terminology.

This hierarchy (several episodes = 1 serial; several serials = 1 season) was unusual, but not confined to Doctor Who - it was also done with Batman, The Tomorrow People and a few of the crime/thriller shows in the 1970s. --Redrose64 🌹 (talk) 21:56, 12 February 2019 (UTC)

Yes, they are a more significant usage, but as I said, 28 articles out of 17,794 is a tenth of a percent - exceptionally minimal, to say the least. As for the Inhumans IMAX episodes template, I don't care either way what happens with the template, as I have converted the template to a default infobox for the exact same layout, ready to replace into the article if it is, in fact, deleted.

As for Redrose64's comments, a well type-out explanation, and further reason as to why we should keep and serial and episode titles together, as well as the production code information in the table. -- /Alex/₂₁ 01:38, 13 February 2019 (UTC)

Perhaps you may like to retract your opposition to the Inhumans template merge in that case, as the discussion around it is still ongoing? Regarding the production code, I agree it should be used (and could add that in the serials that have individual episode titles, the production code was the only official designation of each serial). Regarding the titles column/s, I do not see any connection from Redrose64's summary to that. The only argument made in favour of a single title column here has been that it doesn't cause any problems - and it quite evidently causes a big problem for screen readers (and WP:ACCESSIBLE doesn't have to directly cover this rather niche circumstance for that to be the case). U-Mos (talk) 05:01, 13 February 2019 (UTC)

As I said, I don't care which way that discussion goes. All of that, and an alternate suggestion was already put across where the single title column wasn't an accessibility issue. -- /Alex/₂₁ 07:56, 13 February 2019 (UTC)

Understood: so are you going to acknowledge your change of position at that discussion, or shall I? Assuming you're referring to the earlier Galaxy 4 table above, I see looking at that again that (at least some) screen readers would read that in the same order as the version I proposed, in a roundabout, oddly manipulated fashion. It would still fail to distinguish between serial and episode titles, however (remember, screen reader users can't tell if text is italicised or within quotation marks), and is therefore liable to be confusing to anyone unfamiliar with the topic or even read as an error (if mistakenly believed to be first title-director-writer-production code-second tile-first airdate-first ratings etc.). Not to mention the empty cells. I don't see a single advantage to serial and episode titles being in the same column, especially from an accessibility point of view, and I don't see a single disadvantage against the current version in separating them. U-Mos (talk) 09:42, 13 February 2019 (UTC)

No, I am not, in fact, referring to "the earlier Galaxy 4 table above". Please actually be aware of the rest of the discussion before joining in halfway through. I am suggesting the tables as proposed given in the sandbox. As for the quote "remember, screen reader users can't tell if text is italicised or within quotation marks", again, do not summarize all screen readers. The screen reader I used read out the quotes as"quotes". So, again, they are all different. I don't see a single supportable advantage to the above tables. -- /Alex/₂₁ 10:34, 13 February 2019 (UTC)

I am aware of the rest of the discussion, but you didn't indicate which alternate you were referring to - and regardless, the same issues apply, so not sure what the purpose of that rather WP:UNCIVIL interlude was. Yes, I should have more accurately said "some screen readers" - and as "some screen readers" don't report any difference, it's an accessibility issue. There's the advantage. U-Mos (talk) 10:48, 13 February 2019 (UTC)

Do not edit other editor's comments. If you want to post your own, then do so without editing any others. The only other that applies is the spanning of the directors and writers; no accessibility issues are present for the titles in the linked example. As an editor above said: Unless your reader comprises more than 80% of all readers used, it should offer information for us to improve layout but should not become a standard for us to follow. It is not an issue unless it is a mass issue. -- /Alex/₂₁ 10:56, 13 February 2019 (UTC)

Ok, let's use our information to improve the layout as best we can then. Separating the serial and episode titles into different columns seems like a good place to start. U-Mos (talk) 11:01, 13 February 2019 (UTC)

Strongly disagreed. Titles and titles are all titles, and thus belong in a column for titles. No accessibility issues have been raised concerning the titles column for the suggested options. -- /Alex/₂₁ 11:06, 13 February 2019 (UTC)

It's one thing to disagree with a matter, but quite another to deny it was ever raised. I don't think there's any point in continuing to discuss this with you right now. U-Mos (talk) 11:12, 13 February 2019 (UTC)

What accessibility issues were raised concerning the titles column for the suggested options? The issue is concerning the rowspanning columns in the center of the table; that is, the director and writer columns. Again, I don't believe you are aware of the full content of this discussion. -- /Alex/₂₁ 11:16, 13 February 2019 (UTC)

The titles are less an accessibility issue and more of a general issue for all readers, accessibility impaired or not. It's just information put in an incorrect column. A person that can't see will just have a much harder time understanding that the first title is actually not an episode title. --Gonnym (talk) 12:13, 13 February 2019 (UTC)

That's if we assume that all screen readers interpret the content the same. Either way, this discussion is concerning the accessibility issues; if a separate discussion is required about general layout, then I'm happy to participate in that one. -- /Alex/₂₁ 14:36, 13 February 2019 (UTC)

I'm not sure to which comment of mine you replied as your indent or positioning don't match. I've actually replied directly to Walter Görlitz which is why it was where it was. If you can, please fix it so it will be more clear (if you change yours, please change mine as well). --Gonnym (talk) 15:04, 13 February 2019 (UTC)

The "titles are less an accessibility" comment. Apologies for any incorrect indenting; I use the automatic replier. I believe the location should be changed, however, given that Walter Görlitz's replies will no longer be adjacent to your comment where you pinged them. -- /Alex/₂₁ 15:10, 13 February 2019 (UTC)

In that case, as I've stated, the titles are still an accessibility issue, in that for people that can't see, it is not clear what the titles are, as that isn't even clear to people who can see perfectly. It is harder for them as they can't glance at the table and understand from the context that one title is different, enter that article quickly, see it is a story arc article, glance that article and see it has a table with the episode titles, finally get the context that was missing, return back to the list page and continue reading. The column title should make it clear what the title is - which your version does not, while Umos (and mine) attempt to do. --Gonnym (talk) 15:19, 13 February 2019 (UTC)

This seems more of a "what if this, what if that" issue. There's an accessibility concern, but no solid accessibility issue. Screen readers are not broken by the use of the suggested tables. The quotes are what determine if a title is an episode title or a serial title; I believe to determine whether these are read out or not on most readers, we need some form of a more comprehensive report about screen readers. It's hard to argue about them when we ourselves do not use them. If they are distinguished easily on most readers, then given that they are all titles, they belong in a column for titles. -- /Alex/₂₁ 15:25, 13 February 2019 (UTC)

Clarification: My comments of 21:56, 12 February 2019 (UTC) (above) were not intended to be justification for placing the serial and episode titles in the same column, but precisely the opposite: they have different meanings, and so should be in different columns. Consider this: we wouldn't put the writer in the same column as the director on the basis that both are names of people.

On the last point by Alex 21 (talk · contribs), we have a convention that serial titles are italicised but episode titles are quoted. This is a Wikipedia convention, that I don't often encounter outside Wikipedia. Our infrequent readers and newbie editors are probably unaware that such a convention exists. Consider how "Mission to the Unknown" and The Five Doctors are indicated; both are stories that were broadcast as a single episode, yet we italicise one and quote the other. I expect that there was a discussion somewhere, some years ago, but we can't expect everybody to know about it. Consequently, in both of those articles, and also in list articles where these two are mentioned, there are a number of past edits where the title was flipped from one style to the other, and then reverted. --Redrose64 🌹 (talk) 12:11, 15 February 2019 (UTC)

@Walter Görlitz: as you've already tested with 3 different screen readers, would you mind sharing your results? --Gonnym (talk) 12:13, 13 February 2019 (UTC)

@Gonnym: Can't do that. When I was testing it was for a company I was working for and projects on which I was working. They are the owners of that data. It was not for this website, it was for websites that we were developing for other clients who had specific accessibility requirements. Since I am no longer with that company, I don't even have access to the computer with those screen readers. Sorry if I gave the impression that I was testing Wikipedia with those readers. Walter Görlitz (talk) 18:05, 13 February 2019 (UTC)

@Gonnym: the easiest way to get an idea of how screen readers typically perform is to ask Graham87. He's a very experienced editor and administrator, as well as being blind since birth, and the most helpful guy you could wish to meet. I know that Graham has used many screen readers, and I if I remember correctly, the last time I asked this question, he said that modern readers like JAWS can be set to read punctuation like quotes or styles like italics, but that he normally had those turned off. If he spots the ping and has time, he will correct me if my recollection is faulty. HTH --RexxS (talk) 22:49, 13 February 2019 (UTC)

I would greatly appreciate Graham's opinion on the matter as an editor who deals with this very sort of topic on a daily basis. -- /Alex/₂₁ 00:16, 14 February 2019 (UTC)

Indeed, RexxS is correct here. Graham87 04:01, 14 February 2019 (UTC)

@Graham87: thanks for joining the discussion and adding your input. Could you give your input on two issues we still don't have an answer for? Are rowspans starting in the middle of a table, where the previous columns are single rows and the following columns are also single row, an accessibility issue? And to follow-up that, which of the tables listed at User:Alex 21/sandboxM are OK accessibility-wise? --Gonnym (talk) 09:10, 14 February 2019 (UTC)

@Gonnym: Nothing's changed since [[this discussion regarding rowspans linked above, and I prefer the first table in the sandbox because the episode/serial titles are separated. Graham87 09:47, 14 February 2019 (UTC)

Seems we have a pretty clear picture of what works and what doesn't now. @Alex 21: anything to add or can we end this issue now? --Gonnym (talk) 15:42, 17 February 2019 (UTC)

 Done All classic-era season articles have been updated. (FWIW, editing a ping does not trigger a new notification.) -- /Alex/₂₁ 06:39, 20 February 2019 (UTC)

The current module creates false information for The Daleks' Master Plan at Doctor Who (season 3) and The Mind Robber at [[Doctor Who (season 5), whose different episodes were written by different people. The module needs to allow for different entries in the separate rows where necessary (I have literally no idea how or even where to do this). U-Mos (talk) 06:25, 24 February 2019 (UTC)

ACCESS and OVERLINK on an association football page

I have two concerns about the use of {{flagicon}} in lists of sportspeople. I saw one and attempted to fix it. See the knotted knickers at Talk:List of Major League Soccer players with 100 or more goals#WP:OVERLINK. Could someone explain how using that template in a table is not accessibility-friendly? The two editors arguing in favour of it are not addressing the issues as I raised them. Of course, I could be 100% wrong and should be told that. Walter Görlitz (talk) 04:50, 6 March 2019 (UTC)

The flags should be removed per WP:MOSFLAG. --Izno (talk) 13:16, 6 March 2019 (UTC)

Agree, but could you state that in the other discussion? Aside from MOSFLAG, is it an ACCESS concern as well? Walter Görlitz (talk) 15:15, 6 March 2019 (UTC)

I've commented at Talk:List of Major League Soccer players with 100 or more goals #WP:OVERLINK on the two ACCESS concerns that I can see, and I've crafted a partial solution and made a recommendation. There's probably not much more I can do. Cheers --RexxS (talk) 17:02, 6 March 2019 (UTC)

Tables with pseudo-rows created by br tags

FYI

 – Pointer to relevant discussion elsewhere.

I have lost my patience here. Would somebody please explain in that thread why we don't use <br /> to create rows. --Redrose64 🌹 (talk) 18:33, 3 March 2019 (UTC)

Well first, XTHML breaks, <br />, aren't necessary. I know that a few visual editors use it, but we should tell them to get with HTML5 breaks, <br>, instead. I'll let someone else comment on why it's against accessibility as I have found the racing community doesn't follow any standards anyhow. Walter Görlitz (talk) 18:57, 3 March 2019 (UTC)

@Redrose64: I don't think that particular battle is worth fighting, beyond recording an objection on accessibility grounds. If there are only four pieces of information spread over two columns, we might well assume that the screen reader announcing "7, 99"; in one cell and "Kimi Räikkönen, Antonio Giovinazzi"; in the next cell is comprehensible. Of course, having four cells spread over two columns of two rows as in "7"; "Kimi Räikkönen "; followed by "99"; "Antonio Giovinazzi"; would be preferable, but in this case, it's not worth going to the wall over. I've left a comment reminding them that breaches of accessibility get used as precedent elsewhere, but I don't think there's much else I can do. --RexxS (talk) 20:21, 3 March 2019 (UTC)

@Walter Görlitz: My problem is not with <br /> versus <br> - in HTML5, the slash is optional (as is the space), see HTML5 spec section 8.1.2.1. Start tags, item 6 (and item 5 for the space): the two different forms of the tag are treated exactly the same by browsers that are more recent than about twenty years ago. It's only MediaWiki's silly syntax highlighter that thinks that they are different. My problem is that by using either form of this tag they are going against MOS:DTAB and refuse to acknowledge the fact. I'm pretty sure that we have a rule that MOS:ACCESS, being a generally accepted policy or guideline cannot be overridden by local consensus.

If the motor racing people didn't want outsiders to get involved, they shouldn't have slapped a {{rfc}} at the top of the section. --Redrose64 🌹 (talk) 00:05, 4 March 2019 (UTC)

Is there a reason why we aren't adding this information to Wikipedia:Manual of Style/Accessibility#Tables and Wikipedia:Manual of Style/Accessibility/Data tables tutorial? This issue repeats itself over and over and since we don't have it written in the guideline, we need to argue and explain it each time. --Gonnym (talk) 12:08, 4 March 2019 (UTC)

And we shouldn't be changing <br /> to <br>, anywhere, because doing so breaks other things, like one of our most-used syntax highlighters. "Optional in HTML 5" doesn't mean "destroy it on sight".  — SMcCandlish ☏ ¢ 😼  16:08, 7 March 2019 (UTC)

The things it breaks should be fixed. They are not the current statndard. Walter Görlitz (talk) 18:24, 7 March 2019 (UTC)

Floating images

Following EEng's request for clarification, I attempted to explain two accessibility problems at Wikipedia:Manual of Style/Accessibility #Floating elements.

EEng subsequently removed this:

Another problem that may arise is that a right-aligned floating image may be displayed apparently in a section below the one that it belongs to because other right-aligned floating elements above it – such as infoboxes or other right-aligned images – may "push" it down, while in the wikisyntax it is placed in the correct section. Where this becomes problematic, some solutions exist at WP:Extended image syntax#The many-floating-objects problem.

along with most of the previous paragraph, with the edit summary, Aside from the fact that WP:Extended image syntax is just about the most unreadable, impossible-to-understand pages on the whole project, this problem described isn't an accessibility problem. A screen reader will, in fact, read the image description at exactly the correct point, regardless of where the image would appear on this or that visual device. As for sighted readers, the whole point of "floating" material is that it floats,

That is true, apart from 'this problem described isn't an accessibility problem', but we already knew all that anyway. What has been missed is that when sighted readers see an image apparently in the section below where it should be, their inclination is sometimes to move the stack of elements upwards to fix their visual problem. That can obviously lead to images being placed in the wrong section for a screen reader. It's not a big problem, but it is an accessibility problem. I also don't see removal of the link to advice on how to fix the problem as an improvement. I think the issue needs to be mentioned here. --RexxS (talk) 18:57, 7 March 2019 (UTC)

Try this [4]. EEng 19:12, 7 March 2019 (UTC)

Color doc

@RexxS and EvergreenFir: Here, a reference to the useful User:EvergreenFir/sandbox1 was added. Shouldn't that table be moved out of userspace for stability, maybe to Wikipedia:Manual of Style/Accessibility/Colors? —[AlanM1(talk)]— 19:46, 7 March 2019 (UTC)

@AlanM1: I'd be fine with moving it out of userspace. EvergreenFir (talk) 20:06, 7 March 2019 (UTC)

@AlanM1: that's the conclusion we came to in 2015 at User talk:RexxS/Archive 28 #Color table . I've moved it to your suggested destination. If anybody doesn't like that location, they can always move it somewhere else. Cheers --RexxS (talk) 21:42, 7 March 2019 (UTC)

Font size wording

Our guidance on font size currently reads:

Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that <small>...</small> tags, and templates such as {{small}} and {{smaller}}, should not be applied to plain text within those elements.

it's obviously not optimal, as editors have made amendments to it recently. The choice of "plain text" to describe the default text size for the infobox is not great, and Jonesey95 has tried substituting "already-reduced", which I've reluctantly reverted because I've had more than one protracted argument with editors who were simply unaware that the default font size is already reduced in an infobox.

Just for background, an infobox reduces its default font size to 88% of the default font size for the page. It also increases its main header to 125% of that (i.e. 110% of the default font size for the page). That means that, in theory, an editor could apply {{small}}, etc. to part of the text appearing in the main header (even though I can't think of sensible case for that). So the guidance needs to prohibit reducing text size on all of the elements of the infobox that are at default size – what the guidance currently calls "plain text". The only formulation I can come up with is:

Avoid using smaller font sizes within elements that already use a smaller font size, such as infoboxes, navboxes, and reference sections. This means that, within those elements, <small>...</small> tags, and templates such as {{small}} and {{smaller}}, must not be applied to text that is at the default size for the element.

That still feels unwieldy, so are there any wordsmiths who can re-encapsulate the guidance to make a better job of it? --RexxS (talk) 14:49, 1 March 2019 (UTC)

it's obviously not optimal, as editors have made amendments to it recently. Which could be interpreted to mean those amendments are what made it not optimal. I don't think that was your intent. ―Mandruss ☎ 15:18, 1 March 2019 (UTC)

I would argue that the same editors who are unaware that the default font size is already reduced in an infobox would be unaware of what text is at the default size for the element. The average editor has no grasp of the underlying technical concepts, so anything we say will be problematic. I'm inclined to say "don't use small in these elements, period"—which is what the first sentence effectively says anyway. If some knowledgeable editor feels the need to deviate in some exception case, using small for something not already reduced, they can do so with a hidden comment explaining their rationale and justifying the exception. After all, all guidelines are subject to exception by definition, despite the fact that they are usually treated as absolute. ―Mandruss ☎ 16:21, 1 March 2019 (UTC)

The reason for my admittedly awkward change stemmed from this discussion, and from a note by Galobtter in the April 2018 RFC on small text in infoboxes that {small} etc can be used in titles and in |above= without the size getting below 85%. So shouldn't be deprecated there. As for editors using {{small}} in |above=, which RexxS couldn't think of a sensible case for, I believe that I have seen |name= and |native_name= jammed into |above= in more than one infobox, with the native name rendered smaller than the name, but I am unable to dig one up right now. It's not pretty, and I'm not saying it's sensible, but it usually "works" and is MOS-compliant, more or less.

I support RexxS's revised wording. – Jonesey95 (talk) 00:48, 10 March 2019 (UTC)

I'm with Mandruss: just say no smaller text in elements where (most) text is rendered smaller to start with. Exceptions can be debated on a per-article basis. It's very possible a significant number of editors aren't explicitly aware of which parts of, say, infoboxes are rendered at the default size for that element and which aren't... I certainly wasn't until reading through this discussion—and that these parts wouldn't techncially be restricted from being rendered with <small>...</small>. And as several have mentioned, it would seem like a very rare case where someone would be using two or more text sizes in the same rendered-larger section of a rendered-smaller element. Arrgh... I can see why people have struggled on how to word this! —Joeyconnick (talk) 22:56, 16 March 2019 (UTC)

Table colors for film ratings

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Talk:Motion picture content rating system#RfC: Should we install a color scheme with 9 colors in the comparison table?.

Salient comment: "A WP:Local consensus cannot opt out of policy or the MOS, no matter how long ago the last RFC was. We have clear guidelines on which color combinations are effective for color-blind users." I'm not a WCAG colors expert but some of what's being proposed looks wrong to me (insufficient luminosity/contrast differences).  — SMcCandlish ☏ ¢ 😼  06:21, 2 April 2019 (UTC)

@SMcCandish:This website's color scheme will be better, maybe.Zenkaino lovelive (talk) 13:18, 2 April 2019 (UTC)

@SMcCandish:I used this Chrome-extension program, and I made a sample table when color-blind users see in my sandbox. Original source:[5] Me:Protanopia Deuteranopia Tritanopia This color scheme is by this website's color scheme.ABOChannel (talk) 09:52, 3 April 2019 (UTC)

@Zenkaino lovelive and ABOChannel: Please do not split the discussion. SMcCandlish's post above is a notification, in line with WP:MULTI. --Redrose64 🌹 (talk) 20:51, 3 April 2019 (UTC)

Default link color

I'm trying to understand why the default link color I see on Wikipedia is #2A45AC which does not appear in the table at Wikipedia talk:Manual of Style/Accessibility/Colors. Any ideas? I'm using the Vector default skin. --Gonnym (talk) 11:02, 6 April 2019 (UTC)

Which table is that? I see several concerning Doctor Who episodes, but none about link colours. Indeed, the only mention of link colours is in this thread. --Redrose64 🌹 (talk) 18:13, 6 April 2019 (UTC)

@Redrose64: I think Gonnym meant Wikipedia:Manual of Style/Accessibility/Colors (the talk page is redirected to here).

@Gonnym: That's odd because when I log in with a vanilla, unmodified account, the default link colour shows up as #0645AD in the inspector (both FF66 and Opera 58), and I've confirmed that by taking a screenshot and examining the colour in an image editing program. Anybody have any thoughts? --RexxS (talk) 19:11, 6 April 2019 (UTC)

Yes, thank you RexxS, I meant that page and mistakenly linked to the talk page. I used ColorPicker Eyedropper extension for chrome, but when I inspected the element via the Chrome console I got your value. No idea why the extension "sees" it as a different color. --Gonnym (talk) 19:25, 6 April 2019 (UTC)

The default colours depend on skin and browser? Walter Görlitz (talk) 19:31, 6 April 2019 (UTC)

@Walter: they definitely depend on skin (I use monobook on my main account and it's noticeably different). They shouldn't depend on browser, but there's never any guarantee of how some unusual browser might behave, so I try to give full info just in case.

@Gonnym: I think #2A45AC is actually quite close to #0645AD, just a tiny bit redder. I wonder if the ColorPicker Eyedropper caught a piece of antialiased text that had a slightly modified colour? --RexxS (talk) 19:36, 6 April 2019 (UTC)

If that's the case, then maybe. I tried inspecting various "blue" link text to get the #0645AD value and got different results of blue. In this page, the box at the top that says "This is a talk page. Please respect...", when I inspect with the color picker the "a" of "page" it gives me that value. --Gonnym (talk) 19:55, 6 April 2019 (UTC)

If it is an anti-aliasing effect (and a yellowish background will tend to make one side of the character redder and the other greener), then you can try increasing the zoom as high as you can to minimise your chance of picking up a modified pixel near the edge of a character. Cheers --RexxS (talk) 20:41, 6 April 2019 (UTC)

This makes me angry

Have you seen these comments? --Redrose64 🌹 (talk) 21:43, 8 May 2019 (UTC)

I agree that broken screen readers should be fixed, but we accommodate things worse than that, so it's not a problem for me to make allowances for people who have no other choice. Walter Görlitz (talk) 21:49, 8 May 2019‎ (UTC)

It's more that MediaWiki is broken, as I see it. But not easy to fix ... Graham87 09:29, 9 May 2019 (UTC)

One of the problems we face is the unwarranted assumption that MOS only applies to articles, but that's simply not true. The MOS covers three broad areas: documenting conventions; guidance on functionality; and guidance on accessibility. It is reasonable to assume that the first, and perhaps the second, have their greatest applicability in mainspace, but there can be no doubt that the guidance the MOS gives to help make our encyclopedia accessible to all must apply to every page. We need to advertise that more forcefully. To that end, I've just added a brief paragraph to the lead of Wikipedia:Manual of Style to try to make the point. Please feel free to improve it. It may need some support to establish that it is the consensus viewpoint. --RexxS (talk) 10:02, 9 May 2019 (UTC)

And not unexpectedly, it has been reverted without recourse to the talk page where I had already opened a discussion. I'd be grateful for further opinions at Wikipedia talk:Manual of Style # Scope of accessibility guidance. --RexxS (talk) 16:27, 9 May 2019 (UTC)

Canadian legislative layout and accessibility

A change has been made at Legislative Assembly of British Columbia based on a discussion at Talk:Legislative Assembly of British Columbia. It relates to part colours, link colours and other issues related to MOS:ACCESS. Walter Görlitz (talk) 15:19, 13 May 2019 (UTC)

Use of the horizontal rule

The horizontal rule has been used for sometime now to combine episodes in TV episode lists, for example episode 1/2 of Terra Nova (TV series). Last night an IP changed the code to combine the episodes,[6] which is an issue that even went to RfC so I reverted. This resulted in the IP making this edit stating "In that case, fix massive accessibility issue and tag unruly summary" in his edit summary. He hasn't made clear what the issue is but it seems to be use of the horizontal rule. However, I can find nothing in MOS:ACCESS, or in the talk page archives about this issue so my question is, should we be using horizontal rules or not? If so, then this affects many more than the mentioned article and will need to be addressed by the TV project. I've opened a related discussion at WT:TV#Use of the horizontal rule regarding this. --AussieLegend (✉) 07:24, 28 May 2019 (UTC)

• Template talk:Episode list#Sandbox version update
• Wikipedia talk:Manual of Style/Accessibility/Archive 14#Accessibility disagreement -- /Alex/₂₁ 09:27, 28 May 2019 (UTC)

Use of scope="row" for a colored cell with no text

I noticed that some tables, like the reception one at Agents of S.H.I.E.L.D.#Reception use !scope="row" on a colored cell with no text. Is this proper use? --Gonnym (talk) 15:17, 30 May 2019 (UTC)

@Gonnym: Not really. The whole point of marking a row header cell with scope="row" is to ensure that a properly configured screen reader will read out the text of that cell along with the column header before the contents of a given data cell in that row when navigating into that data cell. So if there's no text in the row header, there's nothing for the screen reader to read out, which kinda defeats the purpose of the row header .

On the other hand, it's not a big problem for the screen reader; it's just not as good as it could be. We do at least have people attempting to mark up row headers properly, and I'd hate to discourage them.

Anyway, I've changed to row header to be the numeric column now, so that a screen reader navigating down the 'Rank' column might hear "1, Rank, 43", then "2, Rank, 76", and so on, which is a lot better than not hearing the season numbers each time. If it gets reverted, I'm not going to edit-war over it. --RexxS (talk) 23:35, 30 May 2019 (UTC)

Accessibility of logon page

Tracked in Phabricator
Task T164189

I realise that this is outside the scope of the MOS but perhaps someone will tell me where would be better to raise it.

The initial logon page requires editors to give their passwords 'blind:, they can't see what they are doing or have done. This disables editors with finger control impairment (and able-bodied editors trying to work off a tiny mobile screen). Some other services have introduced a tick-box to say "display password in clear". Wikimedia should do the same. --Red King (talk) 13:03, 4 August 2019 (UTC)

@Red King: WP:Bug reports and follow the Phabricator link there. --Izno (talk) 14:47, 4 August 2019 (UTC)

There is an existing request for this at phabricator:T164189. the wub "?!" 17:45, 4 August 2019 (UTC)

Tooltips for navigation

WP:Manual_of_Style/Accessibility#Text discourages interactive things in articles. How about use of thing like <span title=…> in navigation devices which don’t belong to article body proper? See Wikipedia talk:WikiProject Chemistry #Sidebar periodic table and https://en.wikipedia.org/w/index.php?title=Template:Navbox_periodic_table&action=history&offset=20190816 for a specific case. Incnis Mrsi (talk) 20:04, 15 August 2019 (UTC)

"In articles" refers to the whole article, not just the body text as you seem to think. "Not in articles" means talkpages, documentation, wikiprojects, etcetera. The same conclusion was reached in this RfD.

Anyway, the "navigation" function you mention is already provided as the tooltip you want to use simply shows the linked article. -DePiep (talk) 11:57, 17 August 2019 (UTC)

Wikilinks in section headings

MOS:LINK says "Section headings should not themselves contain links". Is this a matter of accessibility (in which case, it shouldn't happen on any page, including in discussions), or is this a matter of style (in which case, the rule really only applies to the mainspace)? (Please ping me.) WhatamIdoing (talk) 19:59, 24 August 2019 (UTC)

@WhatamIdoing: It's a matter of style these days. JAWS at least used to choke on headings with links (a very long time ago), but it doesn't now and I'm not aware of any other screen readers that do. Graham87 03:01, 25 August 2019 (UTC)

Thanks. I won't worry about it, then. WhatamIdoing (talk) 03:46, 25 August 2019 (UTC)

Rowspan

Lately there has been a trend deprecating the use of rowspan in filmography tables for biographical articles (for multiple roles in the same year) for accessibility reasons. However, though I believe this falls under the guidelines at Wikipedia:Manual_of_Style/Accessibility#Tables, there is no specific mention there of rowspan. If avoiding rowspan is a valid action, it would really help to have somewhere specific to refer editors who challenge it. I'm not sure if this is happening in other types of articles.— TAnthony^Talk 19:45, 28 May 2019 (UTC)

Happens in TV and discography articles as well (and I'm sure in most other places). --Gonnym (talk) 20:04, 28 May 2019 (UTC)

Please have a look at Graham87's comments in Wikipedia talk:WikiProject Accessibility/Archive 6 #Row spans in tables. Screen readers have got better at dealing with rowspans since I wrote User:RexxS/Accessibility in 2010 to examine the issues raised by rowspans in the Opera and Lynx browsers. Rowspans are not the deal-breaker that they used to be, but it's still kinder to screen reader users if we avoid them where we can. Doing so would certainly make a table more easily navigable, and would probably improve its readability for anyone using any assistive technology. Nevertheless I'd be loathe to try to use MOS to prohibit rowspans, because of the inherent inertia in many WikiProjects who will want to do things "the way we always have". We're much more likely to get accessibility improvements across the wiki in the long term by raising awareness and persuading editors of what is best practice in these sort of cases. --RexxS (talk) 20:55, 28 May 2019 (UTC)

WP:FILMOGRAPHY is the guideline specific to this type of table. It used to instruct not to use rowspan at all, but then was changed a few years ago to allow it. So those of us that vandal-patrol film-star articles stopped undoing others' changes to convert to using rowspan, as well as converting new tables to remove rowspan. DMacks (talk) 07:56, 25 August 2019 (UTC)

Abuse of {{transform}}

Looking on this dispute, one may deem that Wikipedians reject the use of {{transform-rotate}}, style="{{transform|⋯}}" and so on to convey any semantic distinction (such as for “making” uncommon characters from common characters with CSS). May I write provision against abuse of transformations into the MoS? Incnis Mrsi (talk) 13:54, 26 August 2019 (UTC)

Does this issue satisfy the criteria laid out in WP:NONEEDNORULE? EEng 14:38, 26 August 2019 (UTC)

Diagonal split color box

Need your input regarding Draft:Template:Diagonal split color box Is this OK to implement? AngusWOOF (bark • sniff) 21:48, 17 September 2019 (UTC)

Combining two background colors allows to cover more cases with reduced palettes.

Color combinations are a visual aid, text is supposed to be enough to read the information.

The current implementation is only intended for very short text, which fits my needs.

It would be possible to add marker classes to divs to help screen readers. 217.162.112.133 (talk) 22:15, 18 September 2019 (UTC)

@AngusWOOF: The template looks fine to me. The documentation really does need to be updated, though.

First, there are two accessibility areas that the template is capable of violating, and I strongly recommend that the documentation should contain warnings not to do so. These are:

• MOS:COLOUR – background and foreground colours should meet WCAG AAA standards for every combination viewed together. Not every reader is a native English speaker and even one character that can't be recognised because of inappropriate colour choices may make the text unreadable for some.
• MOS:TEXTSIZE – no text should be reduced below 85% of the normal page font size'

Second, it's bad documentation to use examples that show the reader how to do something wrong, so I strongly recommend that the documentation should only contain examples that don't breach those two rules.

@217.162.112.133: Hope that helps. --RexxS (talk) 00:00, 19 September 2019 (UTC)

RexxS, thanks. I'll go ahead and approve them to mainspace for further editing. AngusWOOF (bark • sniff) 00:17, 19 September 2019 (UTC)

What I forgot to post here is that it seems to be related to User talk:Cmglee/archive2018#Template:Diagonal split header. --Redrose64 🌹 (talk) 16:56, 19 September 2019 (UTC)

IUCN status

Can someone take a look and tell me if {{IUCN status}} violates Wikipedia:Manual of Style/Accessibility#Text Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text? It's not using {{abbr}} or a similar template, so I'm not sure if it's usage is ok or not. — Preceding unsigned comment added by Gonnym (talk • contribs) 18:02, 1 November 2019 (UTC)

Reading this article and [7] it would seem that this template's usage of the "title" attribute is indeed violating the MoS. --Gonnym (talk) 11:35, 9 January 2020 (UTC)

MathML

Please see my question about the accessibility of MathML, at Talk:MathML#Accessibility - I'm sure the requested answer there will be of use to this project. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 9 January 2020 (UTC)

Likewise Talk:LaTeX#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:12, 9 January 2020 (UTC)

Lotka–Volterra equations seems like a good test page for MathML; do you have a good test page for the LaTeX, Andy Mabbett? HLHJ (talk) 21:17, 1 February 2020 (UTC)

Clarification on policy on column headers in the middle of tables

Many concert tour lists and articles contain headers in the middle of tables (Zoo TV Tour#Tour dates (FA), Rebel Heart Tour#Shows (GA), Not in This Lifetime... Tour#Tour dates (GA), etc. However, this is contrary to MOS:DTT#Avoiding column headers in the middle of the table, which includes: "Do not place column headers in the middle of a table to visually separate the table. Assistive technologies will get confused as they cannot know which previous headers still apply to parts of the table after the first one ... In most cases, the easier solution is to split the table into several sub-tables with explanatory sub-headings" with good and bad examples. MOS:DTT is not a policy nor a guideline. Should it only be considered optional? —Ojorojo (talk) 16:15, 28 September 2019 (UTC)

MOS:DTT contains examples of best practice, so it's not optional in the sense of "at an editor's whim". If there are good reasons why the table's organisation would benefit from having more than one column header in the table, then editors should not let MOS:DTT stop them from doing that, although they really should still add scope="col" to those headers as a help for screen readers. In the years since that advice was written, screen readers have evolved to cope with more complexities in tables, but we should nevertheless be doing our best to accommodate those who still use older versions. --RexxS (talk) 18:26, 28 September 2019 (UTC)

I see no good reason not to fix these cases. I might even argue that those aren't necessary to be represented in the table at all given that the locations are present already. (I would lean slightly to better practice 1 than 2 since the locations are implied by the locations of each of the tour locations.) --Izno (talk) 18:44, 28 September 2019 (UTC)

Thanks. I'll add a comment at WT:WikiProject Concerts and link this discussion. —Ojorojo (talk) 13:47, 29 September 2019 (UTC)

RexxS, Izno: While following MOS:ACCESS for discographies is advised during the featured list review process (that's how I learned of it), it hasn't caught on for good article nominations. I've brought it up at WT:GAN#WP:ACCESS concerns; maybe others' comments would help explain it. —Ojorojo (talk) 16:13, 6 February 2020 (UTC)

GA participants don't usually know much about ACCESS or most MoSes or editing guidelines, and then the GAs are held-up as paragons of correct formatting, ACCESS, MoS, and guidelines rather than the project decisions. Where may I comment? Walter Görlitz (talk) 17:50, 6 February 2020 (UTC)

@Walter Görlitz: I started it at WT:GAN#WP:ACCESS concerns. —Ojorojo (talk) 16:35, 7 February 2020 (UTC)

possible accessibility issue in "football" roster templates

Several years ago, a few editors raised an accessibility concern with accessibility in the template used to list football (or soccer if you prefer) player rosters at {{Football squad player}}. That listing is very compact, but the nationality is hidden and represented in the link and possibly a hover text. They proposed and created {{Football squad player2}}. It's less compact but does list the nation correctly. Both incorrectly link to the nation in violation of WP:OVERLINK. Football squad player2 is not now up for a deletion discussion: Wikipedia:Templates for discussion/Log/2020 February 1#Template:Football squad player2. Feel free to weigh-in there. Walter Görlitz (talk) 00:56, 2 February 2020 (UTC)

There is now an RfC on the format of the template here. Number 57 10:59, 17 February 2020 (UTC)

Since the RfC is discussing the accessibility of the proposed merged template, it may be of interest to members of this project. --RexxS (talk) 15:59, 17 February 2020 (UTC)

SMALLFONT problem

{{LSR}} is embedded into several other infobox templates. For instance in the infobox on Windows 10 the "Latest release" and "Latest preview" fields make calls to the template and with the small tags built into the original, break MOS:SMALLFONT. I left a comment on the template talk nearly three months ago with no follow-up and no change. See Category:Latest stable software release templates. Walter Görlitz (talk) 01:55, 20 February 2020 (UTC)

 Fixed. You can use an edit request template for a faster response. – Jonesey95 (talk) 02:24, 20 February 2020 (UTC)

Thanks. I wanted to gain consensus before using {{edit protected}}, but the anticipated push-back never materialized. Walter Görlitz (talk) 02:31, 20 February 2020 (UTC)

MOS:FONTSIZE has a strong consensus as part of accessibility, so there should not be any concerns. – Jonesey95 (talk) 03:58, 20 February 2020 (UTC)

I never try to push an external consensus. See the issues above at the football template for instance. Walter Görlitz (talk) 05:14, 20 February 2020 (UTC)

MediaWiki changes that affect accessibility

There are several changes to MediaWiki that will affect accessibility. Please see Wikipedia:Talk pages project#Other projects.

In particular:

1. The upcoming Reply tool should make it easier for people to reply (less scrolling through wikitext to find the right place).
2. The proposed signature requirements should make it easier to tell who posted a comment and prevent some messes.
3. The multi-line syntax thing should make WP:LISTGAP easier to handle (just wrap the mess in the new wikitext code, and it all becomes the same list item).

Please put that page on your watchlists, and ping me (here or there) with any information or requests you have. Whatamidoing (WMF) (talk) 18:56, 12 March 2020 (UTC)

WP:THREAD and MOS:LISTGAP suggest different advice

At WP:THREAD, the suggestion is to use colons (:). At MOS:LISTGAP, the examples for best practice use asterisk (*), though the intention here was to convey accessibility issues with mixing different types. This is a bit inconsistent. 84.250.17.211 (talk) 05:12, 18 March 2020 (UTC)

See also MOS:INDENTGAP, further down the page. The point is not that you can only use asterisks, or only use colons: the point is that you should not mix them at the same level. --Redrose64 🌹 (talk) 13:13, 18 March 2020 (UTC)

In reply to 84.250.17.211, I think that we don't have such a problem with normal threaded conversations that simply use colons alone. It's rare for someone to make the mistake of switching from using colons to using asterisks in those cases, whereas in "list-type" threads such as RfCs that use asterisks to delineate each separate !vote, you do find all too often that someone will make the mistake of replying to a comment by using two colons (::) to create an indent, which destroys the list sequence for screen reader users. It's for those sort of errors that we give the examples to help editors understand what should be done. We could simply duplicate the advice in MOS:LISTGAP, giving parallel examples that start with a colon, but I don't think there's any real need to do that. --RexxS (talk) 13:33, 18 March 2020 (UTC)