Wikipedia talk:Manual of Style/Accessibility

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style    (Inactive)
WikiProject icon This page was within the scope of WikiProject Manual of Style, a project which is currently considered to be inactive.
 
WikiProject Accessibility
WikiProject icon This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.
 
Wikipedia Help Project (Rated B-class, Mid-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article B  This page does not require a rating on the project's quality scale.
 Mid  This page has been rated as Mid-importance on the project's importance scale.
 


{{color sample}} and accessibility[edit]

Could somebody with more HTML/colour experience than I have weigh in at Talk:Dust Bowl#A map, at long last regarding the accessibility problems with {{color sample}}? Thanks. Graham87 15:55, 15 January 2017 (UTC)

Template:Episode table print access issue[edit]

The use of colored backgrounds for purely cosmetic purposes when {{Episode table}} is used should be discouraged and forbidden when the background is darkened to the point that the descriptive text is forced to white. As when one prints the page readability can suffer due to printing being limited to either CMYK or grayscale only. An alternative would be to have the print export view disable CSS elements but that could affect the article layout. 101.98.165.25 (talk) 01:41, 24 January 2017 (UTC)

Listgap[edit]

comments at Talk:Upper East Side#listgaps are welcome. Frietjes (talk) 16:03, 24 January 2017 (UTC)

Listgap: a proposal[edit]

@TheDJ, Psiĥedelisto, Graham87, and RexxS:

The problem with listgaps, as I understand it, is that blank lines, which are often meant to provide some visual clues to list structure,

  1. mess up the numbering of ordered lists and
  2. really mess up the organization of the list and sublists for screenreaders, because they affect the semantics in ways that aren't visible to sighted users of unordered lists.

But the HTML <br> tag can produce the same sort of visual break without introducing any actual (as far as code can tell) blank lines. And so it occurred to me that it might be wise to suggest this tag in MOS:LISTGAP as a way to add gaps for visual readers without hindering screenreader users. I started to draft an alternative version of that section in my userspace, and realized further that even without mentioning <br>, the section would benefit from showing the display of each acceptable (‍YesY‍) and not acceptable (‍N‍) example and not just the wikicode.

Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists says

Do not separate list items with line breaks (<br>). Use {{plainlist}} / {{unbulleted list}} if the list is to remain vertical; or consider {{flatlist}} / {{hlist}} if the list could be better rendered horizontally (in-line) as described in the following two sections.

But I believe that that refers to using <br> to visually simulate a vertical list, and for exactly the same reason that I'm suggesting it to visually simulate a gap: that it has a visual effect but not a semantic one.

My draft is in User:Thnidu/Draft: Safe blank lines. I added new paragraphs in boldface, then (facepalm) realized that that probably doesn't help anyone using a screenreader, so I wrapped my additions in plaintext labels "[BEGIN ADDED]" and "[END ADDED]". I haven't expanded all the examples, but if people think this is a good idea, the additional expansions would be pretty obvious to implement.

Please {{Ping}} me to discuss. --Thnidu (talk) 02:10, 1 February 2017 (UTC)

  • @Thnidu: There are a couple of problems with your page: 1) you forgot to add the <br> to your last example, and 2) even adding it makes no difference to the display on my screen. However, adding two <br>s does add extra space. I suspect that different browsers will interpret <br> differently. — Gorthian (talk) 03:27, 1 February 2017 (UTC)
    • Gorthian, oy, and thank you. Looks like I had the right idea, roughly, but didn't get it quite right. And 2 breaks DOES work indeed. I needed them between my 2 star answer here and Graham87's 2 star answer to me, which I think should've been 1 star with a break or two, rather than 2 star, bc it wasn't an answer to you. ... Gotta go. --Thnidu (talk) 04:58, 1 February 2017 (UTC)

    • @Thnidu: The idea sounds reasonable to me in general, but <br/> would be preferred these days. The part of the accessibility guideline about not separating list items with line breaks refers to their use in tables to separate list items instead of semantically correct list markup. Also, your ping didn't work because you added the mentions onto your post; let me do it for you (excluding myself): @TheDJ, Psiĥedelisto, and RexxS: Graham87 03:42, 1 February 2017 (UTC)
      • @Graham87: Uhhhh... yeah. Thanks. I think I'm out of facepalms for today. --Thnidu (talk) 04:58, 1 February 2017 (UTC)
      • @Graham87: About your observation
        The part of the accessibility guideline about not separating list items with line breaks refers to their use in tables to separate list items instead of semantically correct list markup.
        Yes and no. The part I quoted, Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists, is about lists within tables. But the section I cited first, MOS:LISTGAP (shortcut to Wikipedia:Manual of Style/Accessibility § Lists), which my draft text is based on, is about lists in general and doesn't even mention tables:
        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. These 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. Improper formatting can also more than triple the length of time it takes them to read the list. Likewise, do not switch between list marker types (colons, asterisks or hash signs) in one list, unless embedding lists starting at the highest level.
        I should have referred to that section in the first place, not to Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists. --Thnidu (talk) 06:17, 1 February 2017 (UTC)

Module:Chart[edit]

There's some accessibility issues for the Chart module. We need some focus on CSS override and print-ability. — Dispenser 05:55, 6 February 2017 (UTC)

Help with {{TOC limit}}[edit]

Maybe I'm being dumb, but can someone advise how to apply this template without inadvertently setting the Table of Contents above the Lead? I just experimented at Revolver (Beatles album), ended up with this. Thanks, JG66 (talk) 16:47, 7 February 2017 (UTC)

@JG66: First, the {{TOC limit|3}} must be the last item in the lead section - you were putting it between infobox and introductory text. The easiest way to do this is to first ensure that you have "Add an [edit] link for the lead section of a page" enabled at Preferences → Gadgets. Then edit the lead section of the article, and in the edit box, go to the very end of the text. Add the {{TOC limit|3}} on a line of its own, and save. --Redrose64 🌹 (talk) 17:05, 7 February 2017 (UTC)
@JG66: In short, don't put it above the lead. :D --Izno (talk) 17:07, 7 February 2017 (UTC)
  • Ah, many thanks to you both. I coulda sworn I first tried it, in preview, with the template below the lead … Anyway, just as well I opened my request here with: "Maybe I'm being dumb …" Cheers! JG66 (talk) 17:19, 7 February 2017 (UTC)

Columns for references[edit]

Hello, all. I re-started a discussion at the reflist template a little while ago, to see if we could improve accessibility on different screen widths/font sizes. I think that RexxS has a solid solution in that template's sandbox. It's a very widely used template, so I really don't want to screw this up or have to make more than one change. If there's anything else that ought to happen here, or if you have any thoughts on the change, could you please join the discussion over there and let us know? Thanks, WhatamIdoing (talk) 21:16, 20 February 2017 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────

From a recent Tech news:

"You will be able to show references from <references /> tags in more than one column on your wiki. This is the list of footnotes for the sources in the article. How many columns you see will depend on how big your screen is. On some wikis, some templates already do this. Templates that use <references /> tags will need to be updated, and then later the change can happen for all reference lists. [1][2]"

— Preceding unsigned comment added by Pigsonthewing (talkcontribs) 21:09, 20 March 2017 (UTC)

@Pigsonthewing: Already mentioned (several times) in the discussion over there. --Redrose64 🌹 (talk) 21:36, 20 March 2017 (UTC)

Giant leap backward for accessibility[edit]

this is a giant leap backward for accessibility. we have spent so much time taking infoboxes that use <br> to delimit years, teams, caps, ... and convert them to use number-suffixed versions for WP:ACCESSIBILITY. now, Primefac has reversed this progress on Template:Infobox rugby union biography and from all the safesubst: it looks like the intention is to make this permanent. for Template:infobox football biography we had transition code to support both syntax forms to allow for the conversion to the accessible version. we should do that for template:infobox rugby biography as well, and not step backward in time. Frietjes (talk) 18:41, 20 March 2017 (UTC)

You could have left me a note. I was going off of the {{Infobox NFL biography}} merger, in which it was decided exactly the opposite - a general |history= parameter was better than numbered histories. If this is indeed not the case, I will happily go back to the sandbox. I'm just slightly annoyed that the template has been ready for merging for almost two weeks and only after I start substing does anyone say anything. Primefac (talk) 18:45, 20 March 2017 (UTC)
Primefac, I did leave you a note on your talk page. I don't see how I was supposed to notice any sooner than 10 minutes ago. Frietjes (talk) 18:48, 20 March 2017 (UTC)
I meant leaving this thread on my talk page. Sorry for getting bitchy, you're just the second person in as many hours to comment about this template, and just as I was putting it on the autosubst list. Primefac (talk) 18:49, 20 March 2017 (UTC)
And yes, I've reverted my edits; I didn't realize this was an issue, so I will sandbox everything to ensure numbered params are the way it's done going forward with this merge. Primefac (talk) 18:50, 20 March 2017 (UTC)
Primefac, good, thank you. checking {{Infobox NFL biography}} it uses a simple list to give the history, and not a pseudo-table. basically, you should be able to cut-and-paste the contents and not have data alignment issues. Frietjes (talk) 18:54, 20 March 2017 (UTC)
That's a good point, which I didn't think about going in. I probably should have figured something was up when I had to make a ton of exceptions to account for the table-like nature of the rugby IBs. Thanks. Primefac (talk) 18:56, 20 March 2017 (UTC)
One other tip that I've found useful in the past is that Template:Unbulleted list not only produces a proper list that screen readers can use, but it gracefully skips any empty elements in the list, so you end up with a list only containing as many entries as as there are non-empty parameters supplied, thus making it simple to create a single list from multiple parameters. It's not what you want in this case, because each row of data has the same multiple fields, i.e. it's a two-dimensional list that we properly render as a data table. We perhaps need to think about creating a template or module that creates a table which does not emit any html for blank rows (in the same way that {{infobox}} itself does). That sort of facility should simplify creating infoboxes where these sort of data tables are embedded. — Preceding unsigned comment added by RexxS (talkcontribs) 20:46, 20 March 2017 (UTC)
that's basically where template:Infobox rugby biography/section should be headed. you just need to pass in the data and have it remove any empty rows. for the more generic case, we have Module:Aligned table, which could be modified to drop empty rows. Frietjes (talk) 22:06, 20 March 2017 (UTC)

PSEUDOHEAD and definition list[edit]

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 (talkcontribs) 06:54, 22 March 2017 (UTC)
Text amended to avoid potential misinterpretation. —TheDJ (talkcontribs) 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[edit]

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 (talkcontribs) 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 (talkcontribs) 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 (talkcontribs) 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)

Alternate writing style[edit]

====Members====

The current members of the band are:

In the past the band has also featured:

References

  1. ^ Sellsor, Dan (October 11, 2016). "Wovenwar up the aggression on "Honor Is Dead", gear up to tour as a four-piece". Alternative Press. Retrieved October 11, 2016. 
  2. ^ Pasbani, Robert (September 29, 2016). "Guitarist Phil Sgrosso Parts Ways With WOVENWAR". Metal Injection. Retrieved October 11, 2016. 

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)