The following discussion is an archived debate. Please do not modify it. To request review of this BRFA, please start a new section at
WT:BRFA. The result of the discussion was Approved.
Function details: This is an accessibility issue, see
WP:LISTGAP. A list will be generated monthly that includes articles with blank lines between list items. List is generated using
Checkwiki software. AWB will then be run on the list with general fixes enabled. Latest AWB version added the ability to remove these blank lines. Any spaces or tabs on the blank lines and AWB won't fix, these must be done manually (for now).
Discussion
Whitespace cleanup is normally not approved, can you do a couple of manual edits and provide difs below to more clearly demonstrate exactly what you are trying to do? —
xaosfluxTalk00:20, 29 December 2015 (UTC)reply
Xaosflux I understand the whitespace issue and your hesitancy.
Wikipedia:Manual of Style/Accessibility#Lists tells why it is an accessibility issue for screen readers.
Graham87 is a screen reader user and he can tell you about this problem better than I can.
When a blank line appears in a list, Mediawiki ends the list with a </li></ul>. Thus, when you have a list containing a blank line in between each list item, every item becomes a separate list to screen readers. For an example, take a look at the HTML source code for
Achilles#Popular culture. You will see this:
<ul><li>Achilles is portrayed as a former hero who has become lazy and devoted to the love of Patroclus, in <ahref="/wiki/William_Shakespeare"title="William Shakespeare">William Shakespeare</a>'s <i><ahref="/wiki/Troilus_and_Cressida"title="Troilus and Cressida">Troilus and Cressida</a></i>.</li></ul><ul><li>Achilles appears in Dante's <i><ahref="/wiki/Inferno_(Dante)"title="Inferno (Dante)">Inferno</a></i>. He is seen in <ahref="/wiki/Hell"title="Hell">Hell</a>'s Circle of Lust.</li></ul><ul><li>Achilles is the subject of the poem <i><ahref="/?title=Achille%C3%AFs&action=edit&redlink=1"class="new"title="Achilleïs (page does not exist)">Achilleïs</a></i>, a fragment by <ahref="/wiki/Johann_Wolfgang_von_Goethe"title="Johann Wolfgang von Goethe">Johann Wolfgang von Goethe</a>.</li></ul>
.
.
.
The first sample would be spoken by a screen reader as "List of 1 items, a, list end; List of 1 items, B, list end; List of 1 items, c, list end", as opposed to "List of 3 items, A, B, C, list end". Graham8702:39, 29 December 2015 (UTC)reply
Will only perform on unordered lists and only those that use wikicode (ie, *). On an ordered list (ie, #), the blank line is most likely intentional and a bot wouldn't be able to tell between intentional or unintentional. This is the reason AWB does not remove blank lines in an ordered list.
Bgwhite (
talk)
01:27, 29 December 2015 (UTC)reply
Yes and no. Yes, they do reference blank lines ending lists in the bug report. They still want blank lines to end a list. However, the phab ticket's issue is when you don't want a list to end with an empty line or a line without a * or #. The thinking is to add new wikimarkup to say that this is not an end of a list. Blank lines will still cause problems with screen readers will still continue.
Bgwhite (
talk)
03:02, 29 December 2015 (UTC)reply
This makes sense, but are we sure this is a safe task for a bot to do automatically, or are there situations where blank lines would be desired (i.e.
WP:CONTEXTBOT)? At the very least, restricting to reference sections should be safe. —
Earwigtalk04:02, 29 December 2015 (UTC)reply
I cannot think of any situation where a blank line is necessary. The blank line does not show up on the rendered page. The only people who would notice are those that use screen readers. There are more lists in the main article than the ref section. People usually read the article and skip the reference section. Both BG19bot, Yobot and Battybot, along with our manual edits, have been using AWB's implementation of this since September. I'm not aware of any complaints. The only reason to have a blank line is for the editor to "see" things better when editing the page... I'm 100% sure I'll will get complaints because of this reason.
Bgwhite (
talk)
05:18, 29 December 2015 (UTC)reply
@
Bgwhite: It also provides slightly more visual separation between list items, which can help when list items span multiple lines (e.g. character descriptions), but since it actually creates separate lists, this can't be used for accessibility reasons.
nyuszika7h (
talk)
12:00, 30 December 2015 (UTC)reply
@
Nyuszika7H: Try telling that to people when they start yelling. When I moved TOC's per accessibility, I got plenty of heat, including multiple ANI writeups. I expect the same for this.
Bgwhite (
talk)
09:03, 31 December 2015 (UTC)reply
Regarding page sections - is this a general page issue, or does it primarily cause problems only in certain specific sections, such as reference lists? —
xaosfluxTalk16:10, 30 December 2015 (UTC)reply
It is a general issue. No matter where the list with blank lines occur, Mediawiki will convert to multiple separate lists. This also includes talk pages and BRFA request pages like this one.
Bgwhite (
talk)
09:03, 31 December 2015 (UTC)reply
I guess my concern is really about the use of blank lines for edit window clarity, as you pointed out above, which seems like it should be a valid use case; I understand the accessibility issue, but this really feels like it needs a fix in MediaWiki. —
Earwigtalk23:44, 5 January 2016 (UTC)reply
The fix in Mediawiki is not going to happen and it can't happen. The phab ticket above said they will not consider removing a blank line to end a list because blank lines do correctly end lists in a gazillion articles. Look at Graham's example above (ie List of 1 items, a, list end; List of 1 items, B...), how would you like to hear that for a 20 item list? In my book, accessibility trumps the very minor disruption an editor will have, plus it is already in MOS.
Bgwhite (
talk)
01:12, 6 January 2016 (UTC)reply
Let's be clear—I don't mean removing blank lines to end lists, I mean squashing adjacent <ul>...</ul>s when they are only separated in wikitext by a single blank line. As you pointed out above, this has no real use case; it is natural however for editors to try to do it, which leaves us with these accessibility issues. The Phab ticket seems to concern list items only, not entire lists, but maybe I'm not reading it right. —
Earwigtalk09:31, 6 January 2016 (UTC)reply
From the phab ticket, "empty lines unconditionally terminate lists" and "lines beginning with "something else" unconditionally terminate lists". By saying unconditionally, I think that rules out blank lines between list items not terminating lists.
T15223 was closed without action after seven years to not have blank lines terminating numbered lists.
T109905 was submitted this past August to not cause the current dilemma of blank lines between list items. There was developer comment that said, On reflection, I can't imagine any way in which this kind of huge breaking change to how all wikis everywhere work can be justified by the gains we'd get.. So, a MediaWiki fix doesn't looks likely.
Bgwhite (
talk)
22:27, 8 January 2016 (UTC)reply
Just to be clear, this only runs against lists separated by a single blank line? Multiple lines might suggest the lists were intentionally separated. That being said, have we tested the bot on a page where there are multiple blank lines separating lists?If that all checks out, this task overall seems sensible to me. I feel like if there are lists right next to each other, even if intentional, visually there's not going to be a big difference by joining them. Edit window clarity is a fair argument, but given the accessibility benefits and backing of the MoS guideline, I don't think you'll run into too many complaints — MusikAnimaltalk22:49, 14 January 2016 (UTC)reply
Good question. I had not thought of that. In the list of articles I complied, I was only looking for single blank line. But, an article could contain double blank lines between lists. I tested it out and unfortunately, AWB does combine the two separate lists into one. Playing around with the regex in AWB's code did not rectify this. Turns out, as part of AWB's general fixes, if there are two or more blank lines in a row, AWB will delete the extra ones and leave only one blank line left. Phab ticket
T123825 has been submitted to fix this. I have generated a list of articles where this occurs and there are ~1,200 articles. An example of what you are talking is
Transport in Bulgaria#Major roads. Unfortunately, this appears in a small minority of cases. In the majority of cases, the blank lines should be removed and this will need to be done manually. Yea for me!! :( So, I can wait for this fix or I can exclude the union of the two lists.
Bgwhite (
talk)
06:22, 16 January 2016 (UTC)reply
Approved for extended trial (20 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Just make sure the patch works. --
Magioladitis (
talk)
12:11, 25 January 2016 (UTC)reply
Trial complete. I ran on a
list of 40 articles. Running on the first 20 articles identified a problem with AWB and
rev 11837 fixed it. The problem article was
Pope Martin IV. With the fixed version of AWB, ran on the last 20 articles, plus Pope Martin, with no problems. 28 articles in total were edited. The 12 non-edited articles had no AWB general fixes that needed to be applied, thus left unedited.
Approved for extended trial (2000 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. With this being such a large task, and with some community members being extra attentive to "cosmetic" changes, I'd like to keep this under supervision for a bit; do a run of 2000 so that more pages will be hit and we can see if there is any unexpected community outcry. —
xaosfluxTalk00:05, 5 February 2016 (UTC)reply
Thank you
Xaosflux and
Earwig. This is reasonable. February's dump started on the 2nd. I'll wait for the needed dump file to be produced in a few days before starting. Better to go with an updated list.
Things I learned from moving the Table of Contents for accessibility reasons. 1) People will complain, loudly. 2) Edit summary is key to keeping down the complaints. How about, "No blank line between list items per
WP:LISTGAP. This is an accessibility issue for users of screen readers. Do
general fixes and cleanup if needed. Goto
Wikipedia talk:WikiProject Accessibility for information and discussion." The link will goto an example like Graham gave above.
Graham, is it ok to lead people to the Wikiproject Accessibility talk page? Hopefully there will be safety in numbers, more people know and respect you on accessibility issues, and I'm a wimp right now.
Bgwhite (
talk)
06:05, 5 February 2016 (UTC)reply
Bgwhite, I appreciate that you are able to learn from experience, or at least from being bludgeoned. We are not all so wise.
I suggest a minor copy edit to your edit summary proposed above. Something like: "Remove blank line(s) between list items per
WP:LISTGAP to fix an accessibility issue for users of
screen readers. Do
general fixes and cleanup if needed. Go to
Wikipedia talk:WikiProject Accessibility to discuss these edits." I tested this edit summary in my sandbox, and it fits in the space allotted for edit summaries.
Remove blank line(s) between list items per [[WP:LISTGAP]] to fix an accessibility issue for users of [[screen reader]]s. Do [[WP:GENFIXES|general fixes]] and cleanup if needed. Go to [[Wikipedia talk:WikiProject Accessibility#LISTGAP]] to discuss this.
As mentioned above, I concur that this should only run in mainspace. Though, I should note, this is really poor design in the screen reader itself. I mean, back-to-back ol's with only single li's and no intervening text is pretty obviously the same list. Is it even a "screen" reader if all it's doing is reading the code verbatim—not the actual look? :\ --
slakr\
talk /04:46, 6 February 2016 (UTC)reply
If "back-to-back ol's with only single li's and no intervening text is pretty obviously the same list", then we should have no problem in marking them up as the same list, right? --
RexxS (
talk)
14:48, 6 February 2016 (UTC)reply
I don't think the use of HTML comments should be the default way around this problem, as they would gum up the source code. They should only be used in exceptional circumstances. Graham8709:24, 7 February 2016 (UTC)reply
Of the 2,000 articles, 42 were not fixed. AWB doesn't apply general fixes to articles that have <noinclude> tags. These will have to be done manually.
Bgwhite (
talk)
19:12, 17 February 2016 (UTC)reply
Significant time given for community input, and yet no real objections. Don't work too fast, but barring anyone with concerns: Approved. —
Earwigtalk00:07, 27 February 2016 (UTC)reply
The above discussion is preserved as an archive of the debate. Please do not modify it. To request review of this BRFA, please start a new section at
WT:BRFA.