Wikipedia talk:Colons and asterisks

fyi

Just as an fyi, my version of this essay is at User:Isaacl/On wikitext list markup. isaacl (talk) 05:16, 27 March 2020 (UTC)

In my essay, I added some info on how Visual diffs (as viewed from the history or from the Visual Editor) are also more complicated when list styles are changed unnecessarily. isaacl (talk) 17:30, 16 January 2021 (UTC)

Screen readers

A number of comments have been copied from [1]. Sentences irrelevant to the screen reader discussion were removed. — Alexis Jazz (talk or ping me) 19:28, 21 April 2021 (UTC)

• Alexis Jazz, please read Wikipedia:Colons and asterisks. It's not hard. Drmies (talk) 23:08, 20 April 2021 (UTC)

  Drmies, I can never remember and it always breaks, giving me endless bullet points. I've just enabled WP:REPLYLINK to see if this works better. Also, interestingly, the actual problem looking at your link are not the colons and asterisks but malfunctioning screen readers. This problem can't be fixed by our use of colons and asterisks, the screen readers in question have to be fixed. — Alexis Jazz (talk or ping me) 07:17, 21 April 2021 (UTC)

  @Alexis Jazz: It's not "malfunctioning screen readers". It's that screen readers ultimately are not magic and so cannot be expected to be able to understand that formatted text is improperly formatted rather than being intentionally formatted. And yes, we can fix it by properly formatting our text as you've already been told with a link to an explanation. I'll freely admit, I wasn't aware of this for many many years. IIRC I first became aware of it about 2-3 years ago. I don't think anyone even pointed out I was doing something wrong, I was just reading the accessibility guidelines and realised that and realised I need to stop. I sometimes still fuck up. However as you yourself acknowledged, it's fairly obvious when you've fucked up since the visible text gets messy. So when I do that, I just fix my fuck up. It's not that hard! I admit, it's tricky when someone else has already fucked up. I generally dislike messing with others indentation since I know how annoying it is when someone messes with mine thinking I meant something I didn't. I probably should just get over that in cases where it's clearly wrong i.e. mixes indentation styles. But whatever, it means I can understand why people don't want to deal with that and do their best to not make the problem worse when replying when the indentation has already been mixed up, but leave the existing problems intact. However for those like you who are effectively telling people using screen readers to fuck off because you don't care, well I'll say the same to you in reply. Fuck off. There's no reason anyone should give a fuck what you have to say. You're not welcome here, if it came up, I would fully support a site ban of you on this issue alone. Nil Einne (talk) 11:27, 21 April 2021 (UTC)

  Nil Einne, if a screen reader is reading out a pile of garbage, do you: A. Tell all of the internet to stop producing garbage for the love of god or B. Patch the bloody screen reader to filter out the garbage. Our fuckups are irrelevant. We don't help by caressing the feelings of a screen reader. If we still want consistent colons and asterisks, we'll have to get a bot to fix them. Humans have been proven to be unreliable for this task. You're lucky I have a relatively thick skin and a relatively good day, but some of the things you said may be sanctionable. — Alexis Jazz (talk or ping me) 13:14, 21 April 2021 (UTC)

  I've also had issues with this, so I tested it out in the sandbox yesterday (also look at the markup). The trick to not get multiple bullet points is to never leave an open line between two indented comments. Apaugasma (talk|contribs) 14:54, 21 April 2021 (UTC)

  Alexis Jazz The screen reader doesn't know it's being fed garbage, so how is that supposed to be fixed? The only thing we can control is how things are formatted on Wikipedia, so that's the best solution for us here. — The Hand That Feeds You:^Bite 16:44, 21 April 2021 (UTC)

Accommodating screen readers is more than just the right thing to do. It is a legal requirement of the Americans with Disabilities Act of 1990. Purposely refusing to accommodate screen readers after the problem has been identified would leave Wikipedia open to discrimination lawsuits.

National Federation of the Blind v. Target Corporation was a case where a major retailer, Target Corp., was sued because their web designers failed to design its website to enable persons with low or no vision to use it. This resulted in Target paying out roughly ten million dollars. --Guy Macon (talk) 17:13, 21 April 2021 (UTC)

Guy Macon, technically, Wikipedia isn't bound by the ADA - but neither should we need to be. Doing the right thing is foundational, and accommodating screen readers is 100% the right thing. Also NFIB v. Target is in contradiction with the new Winn-Dixie case, and SCOTUS generally considers corporations to be more deserving of the proteciton of law than any other class apart fomr straight, white, Christian men.

Over a quarter of a century ago I was building websites for major retail brands and I recruited a screen reader user to test our work. It took very little effort to get it right, and made a huge difference, as Bob was able to demonstrate.

People make mistakes, but when they double down after the impact of a mistake has been pointed out, and when the people who experience that impact are already self-evidently deserving of our best efforts, well, that is just a dick move. Guy (help! - typo?) 18:49, 21 April 2021 (UTC)

Guy Macon, The ADA won't apply to users on websites, not like this. If I upload a video to YouTube I am under no obligation to provide subtitles. (even though I probably will. that's how much I suck) If I put a flickering image on my user page (no, I won't) I don't get sued by the epilepsy foundation. One might argue that the MediaWiki developers should do whatever they can to optimize the site for screen readers (and they probably do invest a fair amount of time into that), but even that is probably a bit of a long shot in this case. JzG, People make mistakes, but when they double down after the impact of a mistake has been pointed out, and when the people who experience that impact are already self-evidently deserving of our best efforts, well, that is just a dick move. I'm not saying I don't care. I enabled reply-link so if it goes wrong now it ain't my fault. But please don't make this personal. If Internet Explorer is doing something stupid that causes the display to be garbled (who remembers IE6?), I'd say the same: don't expect the whole internet to bend over backwards to fix what Microsoft should fix. Evidently many people have difficulties with the colons and asterisks. You can't educate everyone to change. To solve this problem, you first need to identify which screen readers are affected and which versions. The first place to look at is the screen reader itself. Let us not be so self-centered to believe that MediaWiki isn't used anywhere outside enwiki or that other websites have perfectly clean code. I don't know how screen readers are typically structured, but one option could be to detect talk pages on MediaWiki wikis and remove list information where signatures are present. This would probably be four lines of code or something like that, if screen readers work roughly how I imagine them to work. Locally we could probably fix this with a screen reader gadget. As a more universal improvement, any repeating "start of list end of list end of list end of list end of list" should be reduced. Repeating the same thing 4 times is pretty much never useful because you couldn't keep track anyway, even if you actually have a list in a list in a list in a list. — Alexis Jazz (talk or ping me) 19:38, 21 April 2021 (UTC)

I turned off reply tools because of the colon/asterisk problem. Because I thought that would be a better choice than claiming "not my problem". Levivich ^harass/_hound 20:05, 21 April 2021 (UTC)

The job of screen readers is to provide an oral rendition of the HTML page being viewed. They shouldn't be reinterpreting it to guess what the author of the page really meant to write. MediaWiki software developers are in a better position to make assumptions and change the software's algorithms for generating HTML. The tricky part as always is how to transition to something new. There are lots of existing talk pages out there that would be affected. Distinguishing between the use of lists to convey reply levels versus actual use of lists (say as sample text for the topic of discussion) is not easy. A lot of opinionated editors out there are opposed to talk pages having a special syntax compared with articles. The Wikipedia:Talk pages project has thus focused on layering improvements on top of the existing syntax, and not redefining existing syntax. Yes, the current state of affairs kind of sucks. For better or worse, the reply tool is the only thing on the horizon that could help. isaacl (talk) 20:47, 21 April 2021 (UTC)

Isaacl, I'd guess screen readers would already contain code to optimize popular websites and popular CMSs. The tricky part as always is how to transition to something new. For anyone who doesn't already know, Flow was developed in the past and almost universally rejected by communities. It was a good idea in theory, but in practice.. not so much. Now, between Drmies taking another stab at me, Apaugasma quickly joining in to call me a troll and the general unpleasantness (to put it mildly) in several comments above, I've decided it's not worth my time to investigate the issue or (most easily achievable for me) create a gadget that cleans up the HTML for screen reader users. I won't be creating Phabricator tickets to suggest improvements to MediaWiki either. I can try to help or you can scream at me. Not both. Sorry to those who remained polite, I can take the screaming but it drains my energy. — Alexis Jazz (talk or ping me) 21:55, 21 April 2021 (UTC)

I wasn't referring to Flow, but introducing new syntax or reinterpreting colon and asterisk prefixes in the context of talk pages, as had been discussed in the talk page consultation leading up to the talk pages project. (Risker had a good point that discussions take place everywhere.) This is essentially equivalent to your idea of processing nested lists differently, except at the wikitext source, instead of downstream at the browser and screen reader.

On a side note, I wouldn't want screen reader developers to play whack-a-mole to adapt to the latest idiosyncrasies of popular site X. It would be akin to when people coded sites specifically for the peculiarities of Internet Explorer.isaacl (talk) 22:21, 21 April 2021 (UTC)

Isaacl, fixing this at the wikitext source level (which would have to be enforced by software/script/gadget or bot) would require consensus. The linked consultation is very long, I may read the summary later. And sure, in an ideal world every website takes screen readers into consideration and works perfectly and browsers respect standards. In practice, IE6 was a piece of crap. — Alexis Jazz (talk or ping me) 22:42, 21 April 2021 (UTC)

Yes, I acknowledged already that making a transition is hard. As a simplistic example of possible change: the software could treat any leading *, :, or # as "use the same list type as above", and only pay attention to the last character. There would be lots of details to work out, but in theory the software could be enhanced in a way that caters to how people currently reply to comments. isaacl (talk) 22:52, 21 April 2021 (UTC)

Isaacl, adjusting the software to the way people use it is a good idea. Wikitext was never really designed with threaded discussions in mind, so it makes sense that problems exist. But adjusting MediaWiki will probably take time. Feature requests and bugs that are easier to fix frequently get stuck in limbo on Phabricator for years. And we shouldn't be surprised if the developers would say "well if you really care, install Flow". And to add something to my 21:55 comment: I'm not completely heartless. If a well-established editor that I don't dislike (anyone who screamed at me need not apply) were to contact me who is actually affected by this problem and who would be willing to help testing a gadget, I'd reconsider. — Alexis Jazz (talk or ping me) 07:01, 22 April 2021 (UTC)

There are similarities to the progression of HTML standards. Using nested lists for discussion threads is more based on the visual appearance of the wikitext source and HTML output rather than their semantic meaning. This is much how a lot of web pages use all kinds of convoluted markup solely for their appearance. Eventually Microsoft invested heavily in following standards, while keeping legacy Internet Explorer behaviour available to enable a transition for web designers that were interested in changing. A long-term solution for MediaWiki will likely involve new features (such as those being examined by the talk pages project, which consulted with the community to figure out what features it wanted) combined with a willingness by editors to adopt them. In the short-term, we're stuck with trying to deal with the wikitext source markup at a low-level. Note there's no need to ping me on replies. isaacl (talk) 15:19, 22 April 2021 (UTC)

Mention the HTML list templates?

I think the HTML list templates (see Template:HTML lists) might be helpful to mention in this essay. Sometimes editors want to put a sub-list in their comment, but the native wiki markup can be inadequate. See Help:List#Continuing a list item after a sub-item. For example, you might see something like

* I have the following thoughts.
** Thought 1.
** Thought 2.
: As you can see, I am right. Signature.

which appears visually as

• I have the following thoughts.
  • Thought 1.
  • Thought 2.

As you can see, I am right. Signature.

And the reason they have used a colon for the last line is because they don't want a bullet point, and the native wiki markup doesn't allow you to continue your original comment after you have introduced a sub-list. But instead, you can use {{Bulleted list}} as follows.

* I have the following thoughts. {{Bulleted list|Thought 1.|Thought 2.}} As you can see, I am right. Signature.

which appears visually as

• I have the following thoughts.
  • Thought 1.
  • Thought 2.
  As you can see, I am right. Signature.

Winston (talk) 10:33, 31 October 2021 (UTC)

@Tamzin Hi Tamzin, pinging you since I noticed your last contributions to this essay and you're much more experienced. What do you think? If you agree, could you include it in the essay? I feel like it's kind of related to the "Multi-paragraph replies" section. Winston (talk) 10:44, 31 October 2021 (UTC)

Counterpoint

I'm sorry, but asking editors to act in a way that depends on how wiki markup is rendered is a lost cause, tilting at windmills.

It would be much more worthwhile to develop screen readers (or plugins to them) that understand wiki markup directly, "reverse engineering" the html back into markup, just like Wikipedia can.

I came across similar sentiments over at the help page that discusses variants of </ br> and such. Again, hoping for or trying to change reality in such a way that only "official" or "supported" HTML is used or allowed on Wikipedia (in such a way that telling editors they're using HTML wrong) is wrong and a waste of energy.

Just accept that whatever HTML Chrome or Edge allows (and renders correctly) WILL be used also at Wikipedia, with a very small set of official exceptions.

And from that rock solid assumption base everything else, including the capabilities of screen readers.

I am not trying to be insensitive to people with disabilities. I am trying to present the stark realities, and help my fellow editors to stop wasting their time.

tl;dr: people will keep mixing colons and asterisks as long as it looks reasonable on the page. Don't think the error lies with the editor. The error either lies with Wiki Markup, which should disallow the cases you bring up here, or it lies with screen readers that aren't capable of interpreting correctly the syntax at one of the ten most used web sites of the world.

Once you are able to accept that trying to change people's behavior is not just futile but misdirected (it is not their fault they're using markup in ways that look good!), the only constructive question remains: which do you feel is more likely, that Wikipedia will change its markup, or that you can tweak or create a screen reader that copes with the way the world works, rather than the way you would wish the world worked?

Cheers CapnZapp (talk) 06:38, 31 March 2023 (UTC)

To respond to your second-last sentence: either of these things are about as likely as pigs flying. Re the screen reader point: this blog post is relevant. Graham87 04:59, 1 April 2023 (UTC)

@Graham87: very good points laid out in that blog post; a key point in that post (and what I came here to say) is that screen readers are mostly not free. The American Foundation for the Blind states here that "Prices range from free to $1,200", but the Perkins School of the Blind, reviewing the 5 most common screenreaders here, states that the most popular screenreader in the world, JAWS, costs $90 a year, or a one-time purchase of $900. It's described as the most configurable, but even then, the American School for the Blind notes that JAWS has a public bug tracker with a lot resting on it already (449 open bugs, with 253 closed).

The other 4 entries on this list include free screenreader technology bundled into operating systems, which will only update when an operating system does – and we have no control over what Microsoft and Apple decide to do in terms of functionality there. As another blog post notes, both companies have faced significant accessibility issues in changes they stated were "better". If you can't afford to update your operating system – say there's technology on it that only works on older versions, or you don't have the money, or the hardware you're using isn't yours to update – you'll be sat around twiddling your thumbs and hoping things aren't screwed up in the next update.

When the best screenreader is expensive and still has an extant buglist in the 400s, and when the most available ones are screenreaders we have 0 control over that won't get updated for years at a time, the penny drops, I think.

@CapnZapp: I don't think it's reasonable to ask a disabled person to hang tight while someone else develops a screenreader that is potentially quite expensive to use. I think it'd be a noble idea for Wikipedia to develop a free screenreader that works with our markup, but I don't think it's going to happen any time soon, and asking people to wait violates one of the five pillars of Wikipedia – "Wikipedia is free content that anyone can use, edit, and distribute." If disabled people cannot use it because we refuse to change our editing patterns, we're violating this pillar. The error very much lies with us.

It's not fair to ask people to wait; it also raises a number of questions in my mind. Who's going to develop this, considering we have, as is always reported, massive problems with editor retention and the community wishlist being fulfilled in a meaningful timeframe? Where is the money going to come from to develop this – are we relying on people's volunteered hours? Can we rely on people's volunteered hours to develop something so critical, and simply accept when they can't do it any longer, for whatever reason, seen or unforseen? How is a screenreader that works just for Wikipedia going to interact with screenreaders built-in to browsers in some operating systems? The list goes on. There are answers to some of these questions, but not solid enough ones for me to stake any sort of plan on this, I feel.

On the other hand, changing community attitudes to accessibility and editing habits is possible. We've made huge, sweeping changes like this before – changes to large templates used by thousands every day, such as reference templates, the move away from HTML markup in-text towards our own markup, the list goes on.

Baking accessibility habits like proper Talk page list formatting into editors as they join, and re-educating existing editors' habits, is achievable, much more achievable than developing entirely new screenreader software. It may take a while to achieve, but we have tools to expedite this process – access to cleanup bots, making it part of our introductions to editing, part of our Manuals of Style. We have much more in our arsenal to achieve this in a reasonable time frame than we do a new screenreader just for Wikipedia. A big change would be, say, changing MOS:ITALIC to only mention accessibility templates for different languages, and stating that the use of semantically meaningless italic markup around foreign-language words is bad wikiformatting. Imagine the change that would make.

I appreciate that cleanup efforts and the reformation of editing habits can feel like cleaning the head of the Sphinx with a toothbrush, but they do work. I periodically like to archive the linkcount toolforge page on how many instances of the accessibility template {{Transliteration}} exist on Wikipedia, for instance; between May 2022 and April 2023, total transclusions rose by about 5,000, from 46,697 to 51,456. It doesn't tell you how many editors have used the template, but I use that template a lot, and even that number averages out at me using it 1.3 times a day – and I know I've used it more than that. If it was literally only me adding them in that past year, I've made an impact just by myself, even if a relatively small one. Think about that change compounded over and over in other editors; imagine the changes we could make. It's not hopeless at all.

We have control over how we edit; we have no control over existing screenreaders, and no capabilities to develop a screenreader in a reasonable timeframe. "Don't think the error lies with the editor" falls flat, when you realise that time and time again, we've changed our editing habits because the error did lie with us editors. It lies with us now, and we've got the powers to change it very simply.

(Also – I've added accessibility markup to your original comment.)—Ineffablebookkeeper (talk) ({{ping}} me!) 10:02, 1 April 2023 (UTC)

Indeed, all very good points. I'd just add as a screen reader user that NVDA is a free Windows screen reader that's competitive with JAWS (it does some things better and some things worse). One major thing that holds people back from upgrading it (at least initially) is that add-ons stop working in every new major version (see examples from 2023, 2022, 2021, etc.). To be fair, there is ongoing work to reduce the severity of these breakages. So price/hardware capabilities/integration are not the only reasons that people might be using older versions of screen readers; there is not only the add-ons problem re NVDA but some newer versions of any screen reader might contain bugs or regressions that are intolerable to certain users. Graham87 11:06, 1 April 2023 (UTC)

Your drive, while understandable from an emphatic viewpoint, is not a good idea, Ineffablebookkeeper. Only really bad system UX don't help users to avoid mistakes, instead punishing them when they "err" (really only using the system as it was meant to be used). Trying to guilt users into remembering rules that aren't enforced by the system is a really bad idea. Never forget: People aren't talking to ("It's not fair to ask people to wait") or even thinking about the disabled when they edit Wikipedia. When you feel they disrespect disabled people, that's only in your mind. They are just using the system as it was designed. You really should redirect your energies to a worthwhile target, and I can only see two: primarily the tools, but I guess you could also try to gain traction with WMF. Unless Wikipedia itself helps people write only the HTML that screenreaders understand, people are going to write any HTML that browsers understand. And they are not doing anything wrong when they do this. Please understand that the attempt to "re-educate" (yikes, just the word itself gives me chills) or guilt editors into change is not only fruitless, it creates negative energy in the room, and most importantly: it would be steering towards a bad solution. We should not steer Wikipedia towards a bad GUI experience where you can write some markup or HTML and it looks good and you get no error messages, but where you're admonished for it afterwards (or worse, even accused of disrespecting people with disabilities). Thank you CapnZapp (talk) 16:39, 1 April 2023 (UTC)

@CapnZapp: I'd love to hear some ideas about how to redevelop the tools we're working with; while I think a screenreader just for Wikipedia is an unlikely goal, the reason I've been harping on about raising awareness – not punishing users, which is an angle I think you are hanging on to quite severely – is because redeveloping the tools of Wikipedia is pretty gargantuan. Who knows where to start? I mean, at present, there are templates we have to avoid using within our referencing systems because it messes up output; there's no discernible way for me to set an article's title as transliterated text if it's coming from a language that doesn't use the Latin alphabet, and there's some HTML tags that have semantic meaning, and some that don't. I've been meaning to reform the collection of {{nihongo}} templates for a couple of years, but I literally haven't had the time to do so. I've heard it said by others that the way we encode Wikipedia articles is pretty archaic, and when I think about it it's bizarre I have to dance around certain rules for formatting bits of a website in 2023, like I'm writing a website only in HTML in 2001, and if I get a bit wrong it's going to look or act strange.

I understand the desire for user experience to be positive, not negative, and I do understand that it really is the best way to go about things, to convince people. So I would love to hear some solutions that are workable, as I think increased accessibility, especially increased accessibility that's less tiring to implement, would mean a lot to everyone, sighted editors included. I don't begrudge my time spent adding accessibility templates; it's important to my personal beliefs, it's not a job taken as some kind of snooty I-care-where-others-don't thing. I joined Wikipedia to write about what I care about, and I've taken accessibility as making it more accessible to a wider variety of people. It matters to me that people can read about the things I care about, and it bothers me to know there are areas of interest that need a lot of work in terms of accessibility, that I don't edit because they don't interest me. I can only do so much, but it gets at me that there's only so much I do.

Even I get tired of adding templates on occasion, though, and it would be nice to have some tools that allow me to not have to think about some things, so I can focus on writing content, not just adding templates. (This would require I sit down and spend time thinking what I want to add, instead of just adding {{cvt}} endlessly to List of apple cultivars while sat on the toilet, but that's a sacrifice I'm willing to make(!))—Ineffablebookkeeper (talk) ({{ping}} me!) 22:20, 2 April 2023 (UTC)