This is the
talk page for discussing improvements to the
Colons and asterisks page. |
|
![]() |
Essays Low‑impact ![]() | |||||||||
|
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)
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)
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)
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)
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)
*
, :
, 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)
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
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
Winston ( talk) 10:33, 31 October 2021 (UTC)
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)
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)
This is the
talk page for discussing improvements to the
Colons and asterisks page. |
|
![]() |
Essays Low‑impact ![]() | |||||||||
|
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)
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)
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)
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)
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)
*
, :
, 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)
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
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
Winston ( talk) 10:33, 31 October 2021 (UTC)
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)
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)