Wikipedia talk:Manual of Style/Accessibility/Archive 13

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

→

Archive 17

tabIndex'ing of Wikipedia

Hi folks, and @Graham87: in particular. I was wondering if I could get some input on this bug ticket, regarding the usage of tabIndex, especially when it comes to the sidebar collapsibles. In my opinion, we might as well set them to 0 now that the rest of the section has been elevated to be under an H2. —TheDJ (talk • contribs) 09:48, 1 June 2013 (UTC)

RfC: What is the scope of this guideline?

Much of this page pertains directly to articles, but could just as easily apply to project pages or Talk pages. What is its scope? Where should it apply, and where should it not? Is there a limit? Personally, I think the scope should be as wide as possible, and the site should be universally accessible to everyone. But some editors clearly disagree with my take, so I’d like to hear theirs, free of all of the above drama. And obviously, if it applies to Talk pages, any edits to anyone else’s comments would be governed by WP:TPO. —Frungi (talk) 06:45, 1 June 2013 (UTC) edited 19:38, 10 June 2013 (UTC)

I think this guideline should be applied everywhere, where practical. The strikethrough discussion above is one example of where it would be almost impossible to apply it on all pages. Graham87 07:14, 1 June 2013 (UTC)

It is sensible to try and follow guidelines like these everywhere but try harder with article pages. A guideline can always qualify where it is supposed to apply. This is just a general observation and does not mean I approve of people hassling new editors and officiously editing other people's comments. See the first sentence of WP:TPO. Dmcq (talk) 20:20, 2 June 2013 (UTC)

This particular discussion isn’t about whether or not we should edit other editors’ comments to make them comply, and I ask that we not discuss that in this section. I had considered creating a new section to specifically discuss that question, but decided to wait to see if this discussion would render that one pointless. —Frungi (talk) 20:55, 2 June 2013 (UTC)

Articles Only, But... I do think we should and must encourage accessibility across the entire encyclopedia, articles, talk pages, project pages, etc. However, I don't believe that a broad mandate across all those spaces fits within the Manual of Style, which is pretty exclusively dedicated to the article space. It may be worth considering promoting this section outside of the Manual of Style, but I really do have some concern about pushing the Manual of Style outside of article space. --j⚛e decker^talk 22:47, 2 June 2013 (UTC)

Very good point. Accessibility should probably be a policy or guideline in its own right, not just part of the MOS. How would we go about proposing that? —Frungi (talk) 23:48, 2 June 2013 (UTC)

It used to be a guideline in its own right, but was recategorised to be part of the Manual of Style in this edit in September 2006 with no discussion that I can find (the user who made that edit was on a guideline-sorting spree at the time). One advantage of it being part of the Manual of Style is that it is automatically part of the featured article criteria, among other things. Graham87 03:27, 3 June 2013 (UTC)

A lot of the rest of the manual of style is just good practice elsewhere as well. However I don't think it should in general apply to talk pages or even WP: pages with quite the same force as it does to articles. Wikignomes going around beautifying things is fine for articles and not a bad thing for WP: pages but in the context of talk pages that sort of thing done by people with no social understanding can be a real menace. The point of Wikipedia is to produce an encyclopaedia and people are secondary as far as article are concerned and that what the first 3 points of WP:5P says. However on talk pages civility and consensus are the important things and that is the fourth point, they are important too on the articles but the talk pages are where the discussion is done. If particular parts of this guideline are good for talk pages then the talk page guidelines should explicitly refer to the particular parts here that are relevant. Anything else is a 'would be nice' that can be conveyed as general practice but people are totally within their rights to reject. Dmcq (talk) 10:00, 3 June 2013 (UTC)

Referring to accessibility fixes as "beautifying" and "would be nice" belies a fundamental underestimation, if not a total misunderstanding, of the issues at stake; and the former is a further straw man. All accessibility guidelines are "good" [sic: read "necessary"] for talk pages. Rendering talk pages inaccessible to some of our fellow editors is a blatantly uncivil act. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:41, 3 June 2013 (UTC)

(Dummy reply for example purposes—see below.) —Frungi (talk) 13:56, 3 June 2013 (UTC)

And [1] is some text that Frungi moved from here away from their RfC where I replied to Pigsonthewing. Dmcq (talk) 07:59, 8 June 2013 (UTC)

Article space only unless explicit. Some of the guidelines should apply to all pages. However, the one we are talking about (elsewhere on this talk page; technically not here) detracts from readability and editability by sighted, but possibly otherwise disabled, readers and editors. I would have to ask Graham whether the blank lines make it easier for a blind editor to, well, edit the talk page, but I agree that the "Wall of text" could be, and in fact, has been, a problem for me. (Note that I'm violating the guideline here, as I've started a new list.) — Arthur Rubin (talk) 13:39, 3 June 2013 (UTC)

You did not start a list; you started a paragraph outside of any list. On a brief tangent from the point of this RfC, addressing your concern about sighted accessibility, do you think it hurts readability for otherwise blank lines to contain colons? See my dummy reply above for an example. —Frungi (talk) 13:56, 3 June 2013 (UTC)

The dummy reply above works for me, in terms of helping readability in the edit window. What does the HTML look like? — Arthur Rubin (talk) 14:23, 3 June 2013 (UTC)

No change to the HTML, in fact. Also no change if done on the same indent level, in the middle of a comment or in between two users’ comments; lines consisting solely of colons are ignored. —Frungi (talk) 14:43, 3 June 2013 (UTC)

I should have checked better. So doing that is not a substitute. It just makes the source easier to read. I found I had to stick in something like   to get a blank line in the output. A half line spacing sometimes would be good too as a full space line is normally too much but that's not going to happen except in a template. I find it annoying too sticking in blank lines at the top level but not sticking in blank lines in an indentation. I really can't see what the problem with implementing it in wiki software is - it isn't as though it can't detect very easily that it isn't in a definition list using semicolons in fact it has to carry around ernough of the state to do this properly just to detect that it should start or end a list. Dmcq (talk) 15:00, 3 June 2013 (UTC)

Agreed; <div>s or something would make much more sense. I’m not sure how the nesting could be implemented for screen readers, though. Still a bit off topic here, but is there anything we can do about that beyond Bugzilla (or just waiting for a new system)? This bug (T6521) is six and a half years old. —Frungi (talk) 15:12, 3 June 2013 (UTC)

Article space only However its use can be encouraged elsewhere and any accessibility solutions should be consistent with it. WP:TALK and Help:Using talk pages are the right places to put things about talk pages and if there is a common accessibility problem in talk pages then that is the place for a guideline about it even if just a short description of the problem with the usual solutions and a link to a section here about it. Dmcq (talk) 14:02, 3 June 2013 (UTC)

Everywhere: Whatever arguments are adduced in support of accessibility considerations for those reading articles apply with exactly the same reasoning to all other pages on Wikipedia. That is assuming that disabled readers are just as welcome on other pages - and I've seen no arguments contradicting that view yet. --RexxS (talk) 16:05, 3 June 2013 (UTC)

Everywhere but it won't be mandatory for talk pages rather than for articles. It would be a guideline for talk pages, maybe like a how-to. Ramaksoud2000 ^{(Talk to me)} 01:46, 4 June 2013 (UTC)

I have a concern. Recently, several editors who are involved in this RfC were involved in a failed attempt to expand the accessibility guidelines that were specifically written for Wikimarkup lists so that they apply to all talk pages, arguing that the talk page you are reading right now is really a list, the comment you just wrote is really a list item, and thus the guideline that was written to apply to Wikimarkup lists applies to your talk page comments. Now I do not want to re-hash the merits of that argument in another place, but I am concerned that votes that agree with statements like "the scope should be as wide as possible" and "this guideline should be applied everywhere" might not be interpreted as meaning "the guideline on lists should apply to lists on articles, lists on talk pages, lists on template pages, etc." but rather "the guideline on lists should apply to lists, talk page comments, and various other elements to be specified later." Now I could very well be completely wrong on this, and there might not be anything to be concerned about, but if enough people vote for "apply the guidelines everywhere" and if such a result is interpreted the way I think it will be, then we are going to end up having Yet Another Battle, this time over whether those who voted on this RfC knew what they were voting for. --Guy Macon (talk) 02:47, 4 June 2013 (UTC)

Your "attempt to expand the accessibility guidelines that were specifically written for Wikimarkup lists so that they apply to all talk pages..." claim is false; as has been pointed out to you more than once. And this comment is a list item...

.. as is this one...

...and this one, as a cursory inspection of the HTML markup will show. Oh, and we don't vote on Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:15, 4 June 2013 (UTC)

There was no "attempt to expand" this guideline to Talk pages. It was assumed that it already covered them, because why wouldn't it? Some, such as yourself, clearly disagree, and that's the point of this RfC—to determine where it does and does not apply, or where the community believes it should or should not.

As for whether anything that is implemented as a list should be treated as a list, or whether Talk indentation should be implemented as a list, I suppose that should be brought up with the technical folks at MediaWiki. To your legitimate concerns, if consensus here is that the guideline in general should apply to Talk pages, we can have a later discussion regarding the specifics, and I will save any further Talk/LISTGAP arguments for if and when that happens. But that is not the point of this RfC. —Frungi (talk) 13:44, 4 June 2013 (UTC)

Request to all participants in this RfC: Let's not yet discuss the specifics of how any particular part of the guideline may or may not apply to any particular quirk of the software outside of article pages. It's simply a waste of time while it's unclear whether the guideline applies outside of article pages, and muddies up the discussion. —Frungi (talk) 13:51, 4 June 2013 (UTC)

And hopefully it's completely unnecessary to say this, but: A decision here to apply the guideline to Talk pages is not license to apply it in controversial ways without further discussion. —Frungi (talk) 13:55, 4 June 2013 (UTC)

You have seen the evidence so far, how can you ever imagine that is something you can assume? Dmcq (talk) 19:05, 4 June 2013 (UTC)

By never giving up hope. —Frungi (talk) 19:37, 4 June 2013 (UTC)

Everywhere, but of course within reason. We want all users to be able to read all the pages. we don't want to tell some users that their participation is unwelcome or should be needlessly painful. This statement is true regardless of whether the issue is quietly indenting the newbie's comments with the correct number of colons (which we do hundreds of times a day, without anyone getting upset) or quietly removing blank lines that slow down the page for people using screen readers. This statement is true regardless of whether the question is an AFD or a talk page or an article. Everyone should be welcome everywhere, not just in articles. We don't have to be nasty about any of this, and it doesn't have to be "important" or take time away from article writing, but we should fix it when it when we run across it, or at least not object to other people fixing such problems. (In fact, the ideal solution to the LISTGAP problem on talk pages IMO is to have the archiving bots fix it. They're already removing stray blank lines after section headings.) WhatamIdoing (talk) 19:10, 6 June 2013 (UTC)

A bot would be less likely to cause arguments, does something need to be specified as a guideline which applies everywhere for that to happen or could it just be done as a general good principle without having editors encouraged to edit each other's comments and quote wikilinks? We really don't need to encourage editors to edit each other's comments I think, it is just a recipe for conflict. Dmcq (talk) 20:20, 6 June 2013 (UTC)

Some editing of other editors' comments is encouraged: see WP:TPO. I'm pretty sure this sort of edit is covered there as "fixing format errors". But, again, I feel this is getting ahead of the discussion (unless you think the consensus is broad coverage?). —Frungi (talk) 22:48, 6 June 2013 (UTC)

off-topic replies by Dmcq and Frungi hidden by Frungi

And I have repeatedly noticed you editing mine to insert comments in the middle as per that section. But I really don't see why you do, you split up what I say. I don't write reams of stuff, and yet there you are saying what I said was long and needed to be split to put in a reply. And I'm fairly equable about things I think, there are lots of people who really do not like other people messing with what they say and just saying you have a right to do so is to make them even more annoyed. Dmcq (talk) 23:02, 6 June 2013 (UTC) That wasn't my intent or my opinion when I did the split replies. I just thought my reply made more sense when it (slightly) more directly followed the relevant text. I've actually only recently started doing it at all, but now that you've pointed out the problems with the way I was doing it (thank you for that), I apologize and I'll stop. Please feel free to refactor my comments out from the middle of yours, if you wish. —Frungi (talk) 00:33, 7 June 2013 (UTC)

So "Editing—or even removing—others' comments is sometimes allowed. But you should exercise caution in doing so, and normally stop if there is any objection", is being read as "some editing is encouraged", whatever about the " It tends to irritate the users whose comments you are correcting." Is that correct? Dmcq (talk) 09:11, 7 June 2013 (UTC)

Maybe “encouraged” was too strong a word. But it does say those kinds of edits are “appropriate”. Anyway, that’s a discussion for WT:TALK, or for the Talk page of a problematic editor, I think. —Frungi (talk) 17:05, 7 June 2013 (UTC)

Can I point yet again at WP:5P "Be open and welcoming to newcomers. ". Having people go around editing other peoples comments causes trouble. I see it as officious people editing newbies comments and driving them away. It is not in the least consequence free. Encourage yes but a bot can do that, You and the other person here who edits other peoples comments just demonstrate the real downside to anything like this. Why can you not see what harm you are advocating? I really would have preferred an answer about the bot rather than you jumping in. It was unnecessary and you hid my reply to you as if what you said was more worthwhile than what I said. Dmcq (talk) 22:10, 7 June 2013 (UTC)

WAID, or anyone else, is still free to reply to your comment or not as she wishes. To the rest of your reply: I hid my reply to your hidden comment as well, because, like it says there, both were off-topic. That's because this discussion is not about the issue of editing other editors' comments, and it is not about debating the merits of WP:TPO as you're doing here. For that, I would recommend WT:TALK, but this RfC, and this Talk page in general, doesn't seem the place for it. —Frungi (talk) 22:57, 7 June 2013 (UTC)

The first sentence of this RfC that you yourself stuck in is 'Much of this page pertains directly to articles, but could just as easily apply to project pages or Talk pages.' Exactly what are you proposing should actually happen in practice? Why did you raise this RfC in the first place? Perhaps you should have answered that question before raising the RfC but the context of the RfC is a person pushing this guideline in a talk page despite objections so what do you support? Your own actions indicate you wholly support editing other peoples contributions to talk pages and take little notice of objections. Dmcq (talk) 23:13, 7 June 2013 (UTC)

Put simply, I raised this RfC to see if there was any point in discussing the WP:LISTGAP controversy. If the community in general wants to limit this guideline's overall scope, then any further discussion on the matter is moot. If not, then we can debate details later. I'm not going to repeat myself here in defending my own actions (click "show" on the hidden content for that, and contact me directly for more), but I support applying this guideline to everything possible, in every way possible, within the bounds of our other rules—such as TPO, which says to stop if there is any objection to fixing a fellow editor's mistakes. —Frungi (talk) 23:59, 7 June 2013 (UTC)

You said your hiding was 'ironic' in your comment because you knew I was saying I had noticed your edits to my comments and wasn't keen on them, and yet you went ahead. You did not stop. Does a person have to raise a complain at ANI before you think it is a request to stop? If you wanted to hide stuff why did you not hide what you said first instead of what I said first?

If a guideline is to be 'applicable' it has to be applicable in some way with some action being done. Otherwise it is just words. That is even worse than creep. It is pretty obvious from what say that what you would actually do is exactly the same your fellow editor that you said was an isolated case in causing trouble on talk pages using this guideline. Not that you take any notice of what I say because to you I am just a fellow editor making mistakes. Just consider for one tiny microsecond in your life that you might make a mistake. Dmcq (talk) 07:20, 8 June 2013 (UTC)

If you wish to discuss my conduct in relation to WP:TPO, then I don't know why you still haven't replied on my Talk page, but please either contact me directly, or post on another appropriate Talk page (e.g. WT:TALK) and drop me a note to check it, and I will be more than happy to defend myself from personal attacks. But this particular Talk page is for discussing and improving WP:ACCESS. Please try to keep that in mind.

To the concern of what I would do if this guideline was declared to cover all Talk pages: After getting that question out of the way, I was planning to determine whether WP:LISTGAP in particular ought to apply to Talk pages, and if so whether it would fall under edits allowed by TPO. I'm not sure whether the best way to do so would be to hold another RfC here or to ask in a more general area; I'm still not sure of best practices for this sort of thing. But if it did apply and was permitted, then, and only then, I would correct that error if I came across it, just as I correct spelling and formatting errors in articles when I come across them. And if an editor reverted that correction or otherwise objected to it, I would not re-revert and would attempt to remember not to repeat the action on any of that editor's other comments (just as I stopped interrupting your comments when you voiced objection). But until this question is decided, I feel that discussion and concern of the sort that has dominated this Talk page (even here ) is moot.

And like I said in my response to you on my own Talk page, editing the contributions of others is not the only way to apply a rule (and hopefully not the primary way that anyone does so). First and foremost should always be following it oneself. Beyond that, if necessary, we could attempt to increase visibility of the rule, or simply mention it to editors who don't seem to be aware of it. Nothing new here, as far as that goes. —Frungi (talk) 11:51, 8 June 2013 (UTC)

I have added a comment to a previous part of this RfC where Frungi moved my reply to a different talk page section altogether and left no notice and I have amended the hide above to describe how that sort of thing causes trouble. Dmcq (talk) 08:09, 8 June 2013 (UTC)

Please! Enough! I'm going to flip this table and spill the WP:TEA if these tangents and hostilities continue. Empathy empathy empathy. We're all encyclopedia editors FFS, misunderstandings happen and we AGF and get back to working on interesting things. Yes? Good! –Quiddity (talk) 22:48, 8 June 2013 (UTC)

• Everywhere per User:RexxS. We should consider our readers and our editors too. The Rambling Man (talk) 19:06, 7 June 2013 (UTC)
• Everywhere when possible, per Graham87, WhatamIdoing, RexxS, et al. –Quiddity (talk) 22:48, 8 June 2013 (UTC)

Since you're so good at empathy, perhaps you could explain what the RfC implies in actual terms as far as a talk page is concerned if it passes? Or do you consider the consequences as a tangent and we should not talk about consequences when talking about an RfC? Dmcq (talk) 00:21, 9 June 2013 (UTC)

Are you asking about the spirit of the inquiry (I AGF and hope to hell that this RFC actually is intended to be about accessibility, otherwise we're all really torturing Graham87 for no reason), or are you asking about the pragmatics of how it will likely be used by certain editors based on the entire facepalm that started this debacle? If the former, then: It will hopefully help us make the talkpages and project pages more accessible, in the long run, by including those in our focus. Because I, for one, am a hell of a lot more impressed with the way some of our disabled editors comport themselves, and I'd really like to help more of them contribute. Maybe their civility and non-sarcasm and general optimism will rub off on the rest of us. –Quiddity (talk) 01:13, 9 June 2013 (UTC)

I am asking for a bit of pragmatism, as WP:POLICY says "guidelines are meant to outline best practices for following those standards in specific contexts". I asked if a bot could do the major things as that would not cause much dissention. But seemingly more than that is wanted. So exactly what more is wanted except for the conflict that started off this RfC in the first place?

Try these for simplicity, a new user comes along and does something that fails the accessibility guideline like not putting in an alt text for a picture of a mushroom when asking a question on a reference desk. Should we as a matter of course start making changes to their query? On a talk page there's conflict, should we encourage editors on them to edit the comments of others? Does an extra space line to outline something but which causes extra words to be output by some screen readers count as reasonable grounds to edit others comments? Dmcq (talk) 11:52, 9 June 2013 (UTC)

Try this instead for a real example: a new user comes along and starts putting blank lines between every indented comment on a talk page. Do I have to explain each time this happens that the mediawiki software will terminate a number of lists and start several new ones which is a real nuisance for some screen reader users? Or shall I simply ask them to look at an agreed guideline (LISTGAP) that explains the problem and helps them empathise with disadvantaged readers? I'm not interested in reverting other editors' mistakes - they can do that themselves when they have an informed perspective on the effect of their actions. There will be cases where judgement will allow a blank line, but these are exceptions to the general rule in LISTGAP, and editors can't use good judgement if the don't have the facts. But it seems to me that the entire argument so far is about keeping newer editors in ignorance and forcing me into explaining in minute detail every time that the situation arises, simply because some editors are too bloody-minded to accept that a problem exists if it doesn't directly affect them. --RexxS (talk) 12:31, 9 June 2013 (UTC)

There are a number of problems with what you say. Firstly when dealing with an article page we are in telling how it should normally be done rather than asking. You said asking and that is appropriate for talk pages. The right mechanism for asking is simply asking like you said and help pages and essays not policies and guidelines. Secondly on the particular example it is not a list from the user point of view and we most certainly should not deter people from editing by expecting them to get familiar with internal hacks and kludges. Just say there is a problem with how indents are implemented that affects accessibility. Thirdly you may not be interested in reverting other peoples mistakes but if this is a guideline for talk pages then people will take it upon themselves to do exactly that so as to ensure they conform to the guideline just like they fix up articles.

I am not talking about keeping new editors in ignorance, I am talking about having pig-ignorant people come along saying WP:LISTGAP and other guidelines before they can open their mouths. If they are doing a lot of them then certainly advise them of the problem but that's quite different from jumping on them with directions. As WP:POLICY says at the start "There is no need to read any policy or guideline pages to start editing". Fixing formatting on article pages is fine and is not directed at new editors, they will learn eventually from advice. Going around correcting their signed comments on talk pages needs to be dealt with in accordance with WP:TPO "It is not necessary to bring talk pages to publishing standards, so there is no need to correct typing/spelling errors, grammar, etc. It tends to irritate the users whose comments you are correcting. The basic rule—with some specific exceptions outlined below—is that you should not edit or delete the comments of other editors without their permission." Dmcq (talk) 17:00, 9 June 2013 (UTC)

The new example is interesting, and seems worth considering. I'd suggest: Yes, editing another user's talkpage comment to add a neutral/informative alt-text to an image, seems like it would be fine. Not necessary or obligatory, but if someone wants to do so, and is doing it for good reasons, then go for it.

The original problem, LISTGAP, is going to be irrelevant once WP:Flow arrives - (a) because all our paragraphs will hopefully have good spacing between them by default, (b) because current plans are to disallow non-admins from editing other people's comments directly.

In the meantime, I keep hoping everyone else will just drop it. We can't prevent edit wars, or personality conflicts, or editors taking umbrage at imperfect-word-choices or imperfect-code-changes. Dragging this out really isn't going to solve anything regarding that dispute, particularly given the stubborn nature of the editors involved (ie most of us, if we think we're "right" about a subjective dispute, like whether it's better to allow an editor to use linebreaks to space her paragraphs more aesthetically, or better to forcibly alter her comments to meet accessibility ideals): theywe'll keep fixing what we think needs to be fixed. Instruction-creep in either direction will be a net failure.

I still think suggesting a site-wide CSS change, to the default spacing between list items like this, by a couple of pixels, would be the best and only reasonable solution, if something really has to be done. Because it really is clearer to have that gap, sometimes. But then, it would have huge effects on the gigabytes of past archived discussions, and that would need oodles of testing, which I'm not volunteering for.

(TL;DR: I'm heavily in favor of accessibility, but I'm also in favor of non-restrictive options, like adding slightly larger gaps between paragraphs when one wants to. And it irks me when people abuse that option, but not enough for me to want to make a guideline forbidding or enshrining their right to do it.) –Quiddity (talk) 17:52, 9 June 2013 (UTC)

I'm still confused by why Dmcq believes this will upset newbies. Right now, we remove blank lines in bulleted lists (e.g., from their AFD !votes). We remove their blank lines to get numbered lists (e.g., at RFA) to count correctly. We change the number of colons to make the indents line up. We even fix links for them, and occasionally even seriously confusing spelling errors, which intrudes into their actual comments. We basically never get complaints about any of this. But somehow, removing a blank line that is located before the actual comment, with no change to the actual comment itself, is going to have newbies unhappy about "people messing with what they say"? Since when is the blank line before a comment integral to "what they say"? WhatamIdoing (talk) 21:21, 9 June 2013 (UTC)

New user comes along sticks in a comment and puts a space around to space it out an look right as far as they are concerned. space removed per WP:LISTGAP, oh I can't even put in a simple comment without falling over some obscure rule or they've gone and made what I put in ugly or that's not what I intended are they always going to start editing stuff I stick in? That is my worry. Why do we need explicit guidance to do accessibility changes on talk pages except to overrule WP:TPO's guidance on caution? Those other changes aren't explicitly specified as applying to talk pages an in fact WP:POLICY#Not part of the encyclopedia implies they don't automatically apply. I want editors comments treated with respect rather than officiously. Dmcq (talk) 22:01, 9 June 2013 (UTC)

Couldn’t the same concerns apply to using the right number of colons, correctly positioning a reply, starting a new section, using an appropriate section title, etc.? And we’ve all seen comments get stuck in a <pre>...</pre> block due to an unintentional leading space. I’m with WAID: I don’t see how this is anything new. There’s already plenty of opportunity to screw up in trivial ways that are easily fixed. Likewise, there are countless wrong ways to “fix” these errors, mostly by drawing unnecessary attention to them—we don’t fix a newbie’s colon count with an edit summary of, “editor was violating WP:INDENT; corrected and left a stern warning on his Talk.” That kind of nonsense would be unacceptable, and there’s no reason that it would be any more likely to happen with LISTGAP or any other accessibility-related matters. —Frungi (talk) 22:36, 9 June 2013 (UTC)

So why do we need to say this guideline particularly applies to talkpages when the others don't except if somebody wants to get around WP:TPO? If you'll notice WP:INDENT is a WP:ESSAY. Dmcq (talk) 22:54, 9 June 2013 (UTC)

No one’s trying to “get around” anything, and I’ve said previously that editing others’ comments isn’t the only (or even primary) way that this would be applied on Talk. (If you haven’t yet, please read my earlier reply to you.) We’re having this discussion because some people think accessibility is important enough that it shouldn’t be limited to just articles, because no editor should be limited to just articles. —Frungi (talk) 23:03, 9 June 2013 (UTC)

So why do you specially need it to say it applies to talk pages when other guidelines don't for such things? Indentation is applied to article pages too, I do it for example for maths formulae and it is used for for poems and for a number of other purposes too and a space line may be put between such lines sometimes. As to talk pages you've talked about that WP:TPO encourages editing other peoples comments, and though you then retracted that after I complained I must admit your quite frequent editing of my comments has left me less than totally convinced you have taken WP:TPO onboard. Dmcq (talk) 00:25, 10 June 2013 (UTC).

I maintain that my changes were within the bounds of WP:TPO. If you wish to contest that, fine, but not here.

Unless I misunderstand your question, you already have a number of answers from a number of editors in this discussion. As I just said: accessibility is important enough that it shouldn’t be limited to just articles, because no editor should be limited to just articles. That’s one argument for having the accessibility guideline be applicable everywhere. —Frungi (talk) 01:20, 10 June 2013 (UTC)

The question is: Is there an actionable result, that is going to come out of this, assuming that no new editors respond to this RfC. If yes, propose it explicitly, and let's get on with that discussion (pleasenopleaseno >.< ). If not, and you're we're just discussing all the permutations of the different ways we each subjectively respect the talkpagecomments of other people, then... the original editors who started this, many many pages above, have barely contributed in days. I'll suggest again, that dropping the subject, and just not replying to this topic any more, is the best way forward. It's taken up a ridiculous amount of time/space/attention without much benefit. (And for the record, collapsing other people's comments is generally a recipe for tears - allowed yes, recommended no. Lesson learned, I'm sure! As someone said to me years ago, "You're not a real Wikipedian until you've made, and learned from, at least 50 mistakes.") If replies continue, I'll try to ignore them, and just let you use your own time as you see fit. Sorry for giving unasked for advice. Etc etc. Yours, cordially, –Quiddity (talk) 03:36, 10 June 2013 (UTC)

And the actionable result I can see from passing the RfC is that this guideline become applicable to talk pages without the qualification of WP:TPO. We can already apply edits if a comment is causing problems just we should do it sparingly and with a bit of delicacy. The proposer talking about discussing that aspect later when pressed about the effect does not mean it would actually be qualified. And I oppose applying it to talk pages without the WP:TPO. Dmcq (talk) 08:27, 10 June 2013 (UTC)

I'm sorry, but I just don't see how this concern has any basis in reality. Correct me if I'm wrong, but any edit that affects the comments of other editors is governed by TPO, period. And until recently ([2]), ACCESS didn't even mention editing anyone's comments at all. —Frungi (talk) 09:46, 10 June 2013 (UTC)

Well how about amending the RfC to say that any such action would be subject to WP:TPO? Without that it wouldn't be subject to WP:TPO whatever about your intentions. I really don't see how this as something to be left till later after the general principle that all talk pages are subject to this guideline is established by an RfC here. The basis in reality is established by the edit warring on a talk page by their pointing to some gobbledygook here rather than invoking WP:TPO and pointing to a user level explanation, and then this RfC being raised subsequently. Dmcq (talk) 10:15, 10 June 2013 (UTC)

Pointing to some gobbledygook that they themselves added two weeks previously. And this RfC was supported by some who approved of the result of that action and hinted that this RfC would give them permission to force their vision on other editors. I know that some here think that doesn't matter, and I respect that, but I think it does matter. --Guy Macon (talk) 11:34, 10 June 2013 (UTC)

This guideline is not about, and does not encourage, editing anyone else’s Talk page comments, except for the section that you added which points to TPO. Even if it did, it would go without saying that of course TPO still applied, as I’ve pointed out numerous times. I shall remove or alter the text that currently encourages editing anyone else’s comments, though I don’t know why you added it in if you find it so objectionable. —Frungi (talk) 19:07, 10 June 2013 (UTC)

Point to the bit where the RfC says WP:TPO goes without saying. May I remind you about what you said about intent and actuality in WT:POLICY about application of this policy "Yes, it is part of a list. Doesn't matter what the intent is; as far as the HTML, and anything that parses it (including your web browser), is concerned, your comment is a list item". According to that your intent for this RfC is not what matters, what it actually says does. Now how about changing it to say it is subject to WP:TPO and then we can assume it because it is written down? Dmcq (talk) 19:23, 10 June 2013 (UTC)

I thought it was common sense that any edit that affects anyone else’s comments is governed by TPO. I didn’t mention TPO when I started this RfC because, as I’ve said numerous times, this guideline isn’t about editing anyone’s comments. Applied to Talk pages, it’s guidance for your own comments. But if you really think it’s necessary, fine, I’ll add a link to TPO. —Frungi (talk) 19:38, 10 June 2013 (UTC)

TPO has said that list markup can be corrected for months now. See the item that begins "Fixing format errors that render material difficult to read" (and, if necessary, take particular notice that it's not just "renders material difficult to read for sighted readers"). Fixing list markup was explicitly added about six months ago, but the general concept has been there for years. There was no objection to this fixing other people's lists—I've done it hundreds of times without a single complaint—until Guy and Walter discovered that indented threads are technically lists (something I hadn't realized until this dispute, either), and decided that the presence or absence of blank lines in a discussion at [[Template talk:Track listing] was critically important. WhatamIdoing (talk) 19:53, 10 June 2013 (UTC)

Which prompted the question of why this RfC was needed in the first place except to support the business that started this. As to commonsense it disappeared at the same time, as WP:COMMONSENSE says "There is no commonsense". So if there really is a desire to have this unnecessary RfC then yes I really would like it to say qualified by WP:TPO rather than have it "assumed without saying". Dmcq (talk) 19:59, 10 June 2013 (UTC)

Thanks Frungi for the addition of TPO at the start. I think I can support it with that though I can't see the point of the RfC in the first place as we don't have that on other MOS guidelines and they can be applied under TPO as well. Dmcq (talk) 09:00, 11 June 2013 (UTC)

VisualEditor is coming

(This cross-post is identical to the note at the WikiProject Accessibility page.)

The WP:VisualEditor is designed to let people edit without needing to learn wikitext syntax. The articles will look (nearly) the same in the new edit "window" as when you read them (aka WYSIWYG), and changes will show up as you type them, very much like writing a document in a modern word processor. The devs currently expect to deploy the VisualEditor as the new site-wide default editing system in early July 2013.

A couple thousand editors have tried out the early test versions so far, and feedback overall has been positive. Right now, the VisualEditor is available only to registered users who opt-in, and it's a bit slow and limited in features. You can do all the basic things like writing or changing sentences, creating or changing section headings, and editing simple bulleted lists. It currently can't either add or remove templates (like fact tags), ref tags, images, categories, or tables (and it will not be turned on for new users until common reference styles and citation templates are supported). These more complex features are being worked on, and the code will be updated as things are worked out. Also, right now you can only use it for articles and user pages. When it's deployed in July, the old editor will still be available and, in fact, the old edit window will be the only option for talk pages (I believe that WP:Flow is ultimately supposed to deal with talk pages).

The developers are asking editors like you to join the alpha testing for the VisualEditor. This is especially important for people who deal with accessibility, because it always takes a while to write, test, and deploy code—so it's important to get any major problems on the list sooner rather than later. Please go to Special:Preferences#mw-prefsection-editing and tick the box at the end of the page, where it says "Enable VisualEditor (only in the main namespace and the User namespace)". Save the preferences, and then try fixing a few typos or copyediting a few articles by using the new "Edit" tab instead of the section [Edit] buttons or the old editing window (which will still be present and still work for you, but which will be renamed "Edit source"). Fix a typo or make some changes, and then click the 'save and review' button (at the top of the page). See what works and what doesn't. We really need people who will try this out on 10 or 15 pages and then leave a note Wikipedia:VisualEditor/Feedback about their experiences, especially if something mission-critical isn't working and doesn't seem to be on anyone's radar.

Also, the screenshots and instructions for basic editing will need to be completely updated. The old edit window is not going away, so help pages will likely need to cover both the old and the new. The WMF is committed to this long-requested improvement, and it's my impression that nothing short of a complete collapse of the servers will cause it to be reversed, so we need information that will help them get it right. The new editing system will become the default, not the only option.

If you have any other questions and can't find a better place to ask them, then please feel free to leave a message on my user talk page, and perhaps together we'll be able to figure it out. Thanks, WhatamIdoing (talk) 01:08, 7 June 2013 (UTC)

Well ignoring all the missing bits I just tried out a definition list starting with ; and managed to get all sorts of weird effects when editing after doing an undo. The best was where it continuously kept outputting a character. I don't think they can be too important even if colon indenting is. So yes it is pretty near the beginning of the development (I hope!). Yes I totally agree this needs good bug testers and people to check the facilities are adequate for editing Wikipedia and satisfy requirements like accessibility. I would guess the text interface is better for accessibility so there is a need to make sure the Visual editor does not generate all sorts of distracting rubbish. Dmcq (talk) 10:10, 7 June 2013 (UTC)

As I understand it, the VisualEditor does not allow editors to use any of the wikitext markup (directly). if you want a list, you have to click the list button. There doesn't seem to be a list button for definition lists. WhatamIdoing (talk) 23:45, 8 June 2013 (UTC)

Extra line consisting of the same number of colons

Currently, the guideline reads "If a space is needed, insert an extra line consisting of the same number of colons.", please look at the wikimarkup for the following tests in your editing window and then look at the HTML source:

---

TEST A

Comment (level 0)

Comment (level 1)

Comment (level 2)

Comment (level 3)

Comment (level 4)

Comment (level 2, reply to second comment)

Comment (level 5)

Comment (level 0)

---

TEST B

Comment (level 0)

Comment (level 1)

Comment (level 2)

Comment (level 3)

Comment (level 4)

Comment (level 2, reply to second comment)

Comment (level 5)

Comment (level 0)

---

TEST C

Comment (level 0)

Comment (level 1)

Comment (level 2)

Comment (level 3)

Comment (level 4)

Comment (level 2, reply to second comment)

Comment (level 5)

Comment (level 0)

---

TEST D

Comment (level 0)

Comment (level 1)

Comment (level 2)

Comment (level 3)

Comment (level 4)

Comment (level 2, reply to second comment)

Comment (level 5)

Comment (level 0)

---

As expected, test D is far worse than A, B, or C, but it turns out that it matters whether "the same number of colons" means the same number as the comment above or below. TEST C renders to the same HTML as TEST A, BUT TEST B does not. IMO, if we are going to tell people how to tweak the wikimarkup so that it produces a particular HTML rendering, exactly how they should do this should be clarified, with examples.

BTW, I really like the lines with colons idea, and am going to start doing it that way (test C) in my posts. --Guy Macon (talk) 21:21, 10 June 2013 (UTC)

I meant to get back to that. Unfortunately if you separate paragraphs with an empty line starting with colons the software completely removes the line when outputting it, you don't get an extra blank line. You only get a blank line if you stick in something like &nbsp;, I was wondering if there was a better way. It does make it easier to read the source though. rather than it looking like a wall of text. Dmcq (talk) 22:29, 10 June 2013 (UTC)

I don't think that he's trying to get an extra blank line in the page/output; I think he's trying to get some white space in the edit window. The Mediawiki software does not remove the blank line in the edit window. WhatamIdoing (talk) 16:04, 11 June 2013 (UTC)

Just to summarize the tests:

• A has no spacing between replies, and is rendered with each reply nested within the list item whose comment it’s replying to.
• B adds a line (with the same number of colons as the respective comment) after each comment. This separates each comment and its nested replies into two separate list items.
• C adds a line before each comment. This is rendered identically to A.
• D adds the proscribed blank lines between replies. Each comment is its own complete nested structure.

Just in case anyone doesn’t want to examine the wiki/HTML markup. Hope this helps someone. Feel free to edit my comment if I got something wrong or unclear. —Frungi (talk) 17:59, 11 June 2013 (UTC)

Advice needed for styling daggers reliably cross-browser

Hi, please see this discussion at WikiProject Military history. We wish to style the &dagger; symbol properly, in a way that looks more like the 2nd or 5th example in - the default sans-serif version (†) usually looks like the 1st example, which has caused many problems and raised various questions. Please reply there (to keep everything centralized), with suggestions on how to best implement this, and if it is possible to achieve high-percentage reliable styling across browsers. (I've not kept up-to-date with CSS over the last few years, but my tests can be seen a few replies down, in the thread). Much thanks.

Specifically: Are there technical reasons that we should avoid using the following code? If so, is there better code to use?

<span style="font-family:'Times New Roman', 'Old English Text MT', serif">&dagger;</span>

This is regarding {{KIA}} and its specific use as the "Killed in action" indicator, primarily used in infoboxes of battles. See the thread I linked, for full explanation, but basically many editors have indicated a preference for a "serif" styled dagger, but we're unsure whether it can/will cause technical problems, or accessibility problems, if we use the given code. (I did change the template to use that code a few days ago, and one editor is objecting to that change on technical grounds, stating that it does or may cause accessibility issues. Read his comments in the thread, to accurately understand his exact concerns). Thanks.

The above is copied/adapted from my request at WT:MOS/Text formatting. –Quiddity (talk) 19:32, 11 June 2013 (UTC)

The principal problem with the html entity † or the unicode † is that Graham tells me that JAWS doesn't read them out. I created {{dagger}} to return an image † which may take an alt parameter with text of your choosing. Personally I would recommend using {{dagger|alt=killed in action}} as the contents of the {{KIA}} template, which would then produce † and JAWS would read out the alt text "killed in action" (it also gives a hover tip for sighted IE users). Sadly, it's a very plain cross because of the problems of producing anti-aliased images with transparent backgrounds. I uploaded some of my attempts at 'fancy' dagger images, so please feel free to experiment for better results if you're interested in image-based solutions to the problem. --RexxS (talk) 17:46, 12 June 2013 (UTC)

{{dagger}} seems to be used as a footnote indicator, whereas the "killed in action" indicator uses the same symbol but for entirely different reasons. I did see that template, but the non-searchability of the character put me off it. Thanks for your feedback though. –Quiddity (talk) 20:40, 12 June 2013 (UTC)

For whatever it's worth the latest version of JAWS reads out the dagger symbols correctly in all circumstances (but it reads the single dagger as "single dagger", which gets annoying). I had completely forgotten about this conversation until it was mentioned in this thread; JAWS' behavior must have changed in this respect then (when I last tested the symbol I was using JAWS 10). However, the image is still the most appropriate solution for accessibility because the symbol doesn't work in NVDA and a substantial minority of people still use old versions of JAWS. Graham87 01:05, 13 June 2013 (UTC)

image maps in navigational boxes

what's the consensus on this sort of thing? I reverted as possibly problematic, but could use some additional feedback, especially if I am wrong about it being a problem. I, personally, find plain text easier to read, and image maps better for inclusion in articles where the information is also presented in plain text. Frietjes (talk) 21:01, 14 June 2013 (UTC)

Multiple references to the same source

When a single source is cited multiple times in the same article, getting back from the references section to the right section of prose requires guesswork. This is (imo) a bad thing and I have prosed to change it.

For a detailed explanation see Wikipedia:Village pump (technical)#Multiple references to the same source. You are invited to participate in the discussion there. Thryduulf (talk) 00:36, 16 June 2013 (UTC)

VisualEditor

Just a brief note: I know there are rumors floating about that all users will be required to use WP:VisualEditor when WP:Flow rolls out. None of it's true. The design for Flow has always included a fallback for users who use screen readers or don't have Javascript or otherwise cannot use VisualEditor. Even assuming that the Flow team decides to use VisualEditor (which I understand is likely, but not set in stone yet), there will be options for people who have special accessibility issues. Whatamidoing (WMF) (talk) 04:17, 15 July 2013 (UTC)

Thanks for keeping us in the loop. Graham87 07:10, 15 July 2013 (UTC)

You're welcome.

I want to be clear that some things won't work for everyone, and some things will simply be irrelevant. (Graham, I just don't think you're going to care about the amount of whitespace around a comment.) And given the way these things go, it will probably be worse in the beginning than it eventually will be.

If there's something that you especially hope for, or something that's awkward now about talk pages, then feel free to leave a message at WT:Flow with your recommendations. Whatamidoing (WMF) (talk) 17:41, 15 July 2013 (UTC)

And now for something completely different...

...I present to you The Web Accessibility WCAG Theme Song. Enjoy! --Guy Macon (talk) 16:55, 4 June 2013 (UTC)

Another interesting accessibility-related video: watch this one with the sound turned off and captions turned on. --Guy Macon (talk) 17:11, 4 June 2013 (UTC)

That second one doesn’t have captions, unless you mean the hilariously-unreliable automatic transcription. —Frungi (talk) 04:45, 5 June 2013 (UTC)

That's what I was talking about. The combination of the accents and the subject matter make that pretty much the worst automatic transcription I have ever seen. --Guy Macon (talk) 08:11, 5 June 2013 (UTC)

ROFL! I can actually understand the super-duper-fast speech in the first link (though I do have it a bit higher in pitch than the default). This JAWS rap (NSFW) is also amusing. Graham87 03:59, 5 June 2013 (UTC)

Must be from practice using a screen reader at high speeds. I don’t have that experience; whatever it was saying there, it didn’t even sound like words to me. —Frungi (talk) 04:54, 5 June 2013 (UTC)

Good videos demonstrating screenreaders in use

I was wondering about what the experience is like, for a typical regular screenreader user. Does anyone have a particularly good example video, to demonstrate to editors who are semi-familiar with screenreaders, what standard high-speed usage is like? I know Graham has mentioned skipping or clipping off the end of items, but I'm not sure what that sounds like in practice. The best two videos I've found after a while of searching youtube, are

• Demonstration of how Google+ is read by a screen reader by Access iQ (45 seconds, and very insightful and painful, with a lot of unlabelled graphics as links)
• Victor Tsaran: An Introduction to Screen Readers, by the Yahoo Accessibility Program Manager (27 minutes, and very informative for a complete newcomer to the subject, but quite a bit too long. (Oh! The last minute contains essentially what I want)).

(Note that I did watch many more videos, and there an abundance of poor quality recordings, or labored introductions to the topic aimed at non-geeks.) I'm hoping to find something right in between those two; something that demonstrates 2–5 minutes of normal use, by an advanced or smart user. Maybe even something that we could link to from the WP:ACCESS page itself. –Quiddity (talk) 06:03, 5 June 2013 (UTC)

• Sina Bahram demonstrates usage and speed and accessibility issues (9 minutes, incomplete, but interesting). –Quiddity (talk) 14:34, 12 August 2013 (UTC)

Presentational tables

I was unaware of this, so I suspect many others as well. It's actually possible to use role="presentation" on tables, if they are used for presentational purposes. Considering adding this to *mbox... —TheDJ (talk • contribs) 08:40, 13 August 2013 (UTC)

I didn't know about that either, but it sounds like a good idea. Graham87 13:14, 13 August 2013 (UTC)

@TheDJ: Could you explain how this feature works, and what it can or does change, and/or in what contexts it functions, and how widely we should be thinking about using it? Thanks. :) –Quiddity (talk) 17:12, 13 August 2013 (UTC)

Screenreaders recognize HTML tables and handle them with special navigation modes. We still have a few places where we use tables for purely presentational purposes. Those tables don't represent any tabular dataset and we should be using divs and spans for them. However tables have some unique layout features that are not easily possible with divs and spans, especially when it comes to older browsers. A prime example of this are the mbox templates. They use proportionality and are positioned inline taking into account floating elements (info boxes). This is impossible to do with pure divs without seriously affecting the rendering of pages on IE6 and IE7. With HTML5 and WAI-ARIA, you can put roles on elements that tell screenreaders to treat elements differently then their implicit role. You can turn anything into a heading by using the attribute role="heading" or making it a part of a list using "role=listitem". The other way around works as well. By setting role=presentation, you can tell the accessibility layer to ignore any implicit role alltogether by using role="presentation". This latter option is explicitly whitelisted in the wikicode parser. I have applied this to the sandbox version of ambox and you can test with the ambox testcases. The other role values are not available right now, because the idea is that they shouldn't really ever be needed from wikicode (just use what you should use). If we can demonstrate proper uses for inside articles for other roles, we can file bug reports requesting to allow other role values if needed. —TheDJ (talk • contribs) 07:03, 14 August 2013 (UTC)

@TheDJ: Ah, that's great. Much thanks for the explanation. - I've added the code to Template:User info, please confirm that this is the correct usage? Ta. –Quiddity (talk) 18:37, 15 August 2013 (UTC)

I have now executed this for all mbox tables. When using a screenreader though, I note that we really should have something like a label on that whole thing. "Notice, speedy: " prepended to them would already help a lot. I might file a ticket to whitelist aria-label... —TheDJ (talk • contribs) 09:46, 15 August 2013 (UTC)

The Main Page is a prime candidate as well. — Edokter (talk) — 08:01, 14 August 2013 (UTC)

And {{Geographic location}}? Perhaps we should also have a hidden category, Category:Templates with presentational tables? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:00, 15 August 2013 (UTC)

I think that would actually be a bad example for conversion. The reason is that we represent spatial information visually in that template. Adding role=presentational would remove that information, probably making the template less accessible. This can be done, but would require extensive addition of screenreader specific labels etc. to add this information again. Keeping the table at least gives 'order' for now, even though it is not in the way we would want to do it. The main page also has some challenges btw. If you put presentation role on it, suddenly you loose the information of the grouping (a cell is a group). Cells are announced as 'begin of table cell [...] end of table cell', but with role=presentation, it just keeps reading, and you have to infer the grouping from the usage of the headers. Possible, but possibly not ideal. role=section, labelledby=idofheader would probably be more ideal in this case. Actually, even on mbox it would probably be better if we could use role=note. I think we need to realize that 'removing any and all role' (using presentation) is not always more accessible than have an incorrect table role. —TheDJ (talk • contribs) 12:29, 16 August 2013 (UTC)

Flat lists

See Template talk:Flatlist#Accessibility. Frietjes (talk) 15:54, 22 August 2013 (UTC)

Bot request relating to accessibility issues

I've recently done a write-up about accessibility problems on Wikipedia in the Signpost's tech report, and flowing from that, I've started a bot request discussion to fix some accessibility issues that I noted in the write-up. Any comments at the bot request discussion would be appreciated. Graham87 05:16, 7 September 2013 (UTC)

navbox formatting

see Template talk:Cross-Tipped Churches. Frietjes (talk) 20:00, 16 September 2013 (UTC)

Accessibility#Images vs Manual_of_Style/Captions#Special_situations

We have ...

Images should contain a caption, either using the built in image syntax or a secondary line of text. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.

 – Wikipedia:Accessibility#Images

... meanwhile, we also have ...

• Periodic table snippets for each element – no caption needed
• Images of Element samples in the element infobox – no caption needed
• Images of plants and animals, protists etc. in infoboxes – caption optional
• Infobox images with mission insignia – no caption needed, but if there is a description of the symbolism, it should be included on the image description page
• Other images (especially within infoboxes) where the purpose of the image is clearly nominative, that is, that the picture serves as the typical example of the subject of the article and offers no further information – no caption needed.

 – Wikipedia:Manual_of_Style/Captions#Special_situations

It seems that these conflicts require some arbitration (e.g. sub-clausing the WP:CAP#Special_situations items: "except where there is no WP:ALT content" – the basis upon which I acquiesced a recent revert spat, regarding music release cover-art).

Any ideas folks? I'm very interested in technology to accommodate the differently enabled (e.g. abatement of sight-impairment), but have much to learn, in terms of all the prevalent combinations of abilities and aids (e.g. screen readers). – Ian, DjScrawl (talk) 23:07, 14 October 2013 (UTC)

See Wikipedia:Extended image syntax#Alt text and caption, which notes that captions are used like alt text when an image is not in a thumbnail or a frame. In your linked revert spat, the caption would never have been displayed to anybody, because the image already had alt text. Graham87 00:40, 15 October 2013 (UTC)

I've gone ahead and added a link to the special situations for captions in the accessibility guideline. Graham87 00:44, 15 October 2013 (UTC)

Hawt, thanks!

^<joke>And, certainly some semblance of forward motion. _{</joke et British aspie (my chief different-enablement)>}

If I'm reading you correctly, alt is critical. Do you think that's exhaustive and ubiquitous, so for all arbitrations? If so / either way, your fine Ac'Img's change seems to leave that constraint merely inferenced. Assuming ... How about: "Always when alt is not present and in most cases otherwise ...", or to that effect. In which case, all the more importance, since some image-loaded Infobox(es)/templates do not yet surface the 'alt' field. :/

Correspondingly, it seems, Wikipedia:Manual_of_Style/Captions#Special_situations is left directly contra-MOS:ACCESS, insofar as folk're explicitly told not required, regardless of alt-content. How about in interlocking back-linked proviso?

NB1: Pls, forgive my lack of WP:BOLD here – again, it's a lack of insight on coverage of the cases.

NB2: I'm quite proud of my 'alt's and find it fun/helpful to imagine I'm scripting audio description (which I'll check the tips for). – Ian, DjScrawl (talk) 16:31, 15 October 2013 (UTC)

That's almost right ... except it's possible to have no alt text as long as the image link is disabled. I can't really think of a way to summarise this concisely at the moment. Graham87 06:12, 16 October 2013 (UTC)

Oh Bondage! Up Yours!? I also noticed the Special's list looks worth, at least, bisection sub-sectioning (insofar as, there's a hefty split between Preclusions and Other Exceptions). Taking the dive on that (an improvement anyhow, IMO), would then provide a free-text space (para' below Preclusions sub-head) – thus, relaxing the requirement for succinctness. Two birds, 1.2 stones styee. :) Ian DjScrawl (talk) 12:00, 16 October 2013 (UTC)

WikiProject accessibility interview

Just in case anybody interested doesn't have the WikiProject page on their watchlist, see this thread about an ongoing Signpost interview with the project. Graham87 02:34, 18 October 2013 (UTC)

Listgap and Col-break

Can someone explain to Ken at User_talk:Dennis_Brown#Would_you_take_a_look.3F that inserting a {{col-break}} in the middle of a list causes a WP:LISTGAP? Thank you. 174.56.57.138 (talk) 05:35, 18 October 2013 (UTC)

WP:LISTGAP refers only to blank lines, and does not mention {{col-break}} at all. Please read the text! Beyond My Ken (talk) 05:37, 18 October 2013 (UTC)

the omission of tabular column breaks was an oversight. I will correct it. Frietjes (talk) 14:48, 18 October 2013 (UTC)

High resolution

The section at WP:ACCESS#Resolution primarily deals with ensuring that users with low-resolution screens won't be hindered in their Wikipedia experience. Should the same care extend to users with high-resolution screens? For example, {{track listing}} creates a simple table for combining multiple sets of data about a musical album's track listing (track number, track title, writing credits, lyric credits, track notes, track length, etc.). However, when the same template is only used for a few fields (just track title and track length), on a higher-resolution screen, this can cause an ungodly amount of empty space between the two sets of data in the table. And that space gets larger as the screen size increases since the table is formatted to fill the entire screen, whatever the size. Should this MOS be updated to include concerns about higher-resolution screens as well? Fezmar9 (talk) 01:09, 28 October 2013 (UTC)

Chart templates and alternatives

see Talk:Catalogue of Women. thank you. Frietjes (talk) 17:27, 10 November 2013 (UTC)

Line breaks at end of sentences

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was to make the proposed change, which does not seem controversial. Aymatth2 (talk) 02:28, 14 November 2013 (UTC)

---

WP:Manual of Style/Accessibility#Text says:

4.  When editing, never break up a line unless absolutely necessary, as the easiest way to edit with a screen reader is to navigate line by line."

That presumably prohibits adding single line breaks to the end of sentences. The essay Wikipedia:Don't use line breaks gives pros and cons of line breaks within article source text, but despite the title does not come to a conclusion. A poll on Wikipedia talk:Don't use line breaks shows editors about equally split, maybe slightly leaning to line breaks if they are only used at the end of sentences. The main "pro" argument is that diffs are easier to follow if there are line breaks in the source text and the main "con" argument is that they make the source text look even more different from what is displayed. The essay does not discuss accessibility.

My eyesight and coordination are not great: I sometimes find it hard to position the cursor precisely using the mouse. I swap text around a lot when I am working on an article until I am satisfied with the sequence. If each sentence is followed by a line break I find it easier to select the sentence, then cut it and paste it somewhere else. I click and hold in the white space after the end of the line, pull the mouse back to the start of the sentence on the left of the edit box, then CTRL+X, CTRL+V to move it. It is harder for me to select and move text that is embedded in a line or lines because I have to position the cursor more precisely. I also prefer not to overcite. Two or three sentences may have a cite at the end of the last sentence. Before moving one of these sentences somewhere else, I have to copy the cite to the end of it too, which is easier for me with line breaks at the end of each sentence:

While Jardines carried opium for the larger suppliers, the Apcars catered to many smaller local dealers.

With slower boats, they charged much lower rates than Jardines, ranging from Rs8 to Rs10 per chest compared to upward of Rs28 per chest charged by Jardines.

The Apcars may have had private arrangements with the dealers that locked them into using Apcar services.{{sfn|Harcourt|2006|p=104}}

On the other hand line breaks, even when only placed at the end of sentences, make editing with a screen reader a bit more awkward. This seems like a trade-off between making editing a bit easier for some editors at the cost of making it a bit harder for others. I would prefer to change this statement in the guideline to:

4.  Do not insert line breaks within a sentence, since this makes it harder to edit with a screen reader. A single line break may follow a sentence, which may help some editors.

Comments? Aymatth2 (talk) 14:56, 6 November 2013 (UTC)

Sounds reasonable to me, for what it's worth. Also see the relevant discussion at WikiProject accessibility. I think it'd be a good idea to wait, say, a week from your initial posting on this page for any further comments, and then make the change. Graham87 06:27, 7 November 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Collapsing music track lists

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I have decided to start a centralized discussion about collapsing track lists, and the effect this has on users with disabilities. Talk:Long. Live. ASAP#Collapsed sections and Talk:Music_of_the_SaGa_series#Collapsed_sections contain previous discussions about the issue which I plan to continue here. I am not sure how this discussion should be moved over here, so if someone can do that it would be appreciated. --Jax 0677 (talk) 00:09, 1 October 2013 (UTC)

Uh, isn't Template:Track listing designed to have a collapse feature?—Ryulong (琉竜) 03:56, 3 October 2013 (UTC)

Reply - I know that it is designed that way today, however, this does not address the issues of What kind of problems physically challenged people encounter for people who use text only internet browsers nor Wikipedia:Accessibility dos and don'ts. --Jax 0677 (talk) 17:27, 3 October 2013 (UTC)

Accessibility of collapsed content has been discussed previously here (please search the archives). Text only internet browsers have no problem viewing the content because it is expanded by default and only collapsed once JavaScript can run on the page. Have you tried a text only browser and seen it behave differently? --SkotyWA^T_C 19:21, 5 October 2013 (UTC)

Here, I went and found the old discussion. --SkotyWA^T_C 19:31, 5 October 2013 (UTC)

In the arbcom infoboxes case, I gave some Evidence about the usage of "collapse" over the years, and a recommendation that it be researched further and possibly cautioned against more strongly. (Note: one item I missed in my Evidence, was how it breaks ctrl-f searching within a page). –Quiddity (talk) 04:05, 5 October 2013 (UTC)

The ⌘ Command+f failure is increasingly irritating to me on discussion pages, because you get {{pinged}} to a page and then can't find the part that you're supposed to look at. WP:DRN's archives use it for everything. WhatamIdoing (talk) 20:27, 6 October 2013 (UTC)

I agree. I am often irritated to search on a page and find nothing and only later realize there was collapsed content. This is a general complaint. With regards to the specific issue of track listings, editors sometimes add a malformatted entry for a song to a disambiguation page, perhaps only mentioning the artist, perhaps mentioning an unlinked album and I try to assume good faith and find an appropriate target to link to. At times, due to lack of context, it is necessary to browse the discography one album at a time and I rely on Ctrl-F to search the page for the song title. When the track listing is collapsed, I get no hits and move on, which usually results in the entry being removed from the disambiguation page because no article could be found that mentioned the song. older ≠ wiser 20:55, 6 October 2013 (UTC)

• Just saying a discussion related to removing the collapse function from the template has been started at Template talk: Track listing#Collapsibility. STATic message me! 19:34, 21 November 2013 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Font size

I would like to add the following section under text:

The use of font size reducing markup or templates should be used sparingly. In no case should the resulting font size drop below 11px (85% on systems using 96 dpi display setting) to avoid illegible text. A common mistake is the use of smaller font sizes (using {{small}} or inline CSS) inside infoboxes and navboxes, which already use a smaller font size.

Comments? — Edokter (talk) — 18:03, 4 January 2014 (UTC)

On second thought, it would be better served at Wikipedia:Manual of Style/Text formatting. Though a hatnote referring there would be appropriate. — Edokter (talk) — 18:18, 4 January 2014 (UTC)

It should be here as it is an accessibility issue. I have problems reading smaller text sizes and have to increase the web browse size to read things. A hatnote should be at the Text formatting page.

This has been talked about before, but never implemented. It should be.

I'd only mention that it shouldn't drop below 85% or 11px, so as not to get too complicated.

Other places that reducing the size shouldn't be used is in image text, <sup>, <sub> and reference section that use {{Reflist}} or <references />... Anotherwords, wherever the font size is reduced, it should be avoided to reduce even more. Bugs me to no end that some reference sections are so small that I can't read the dang thing. Bgwhite (talk) 19:22, 4 January 2014 (UTC)

2nd draft:

The use of reduced font sizes should be used sparingly. Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections. In no case should the resulting font size drop below 85% of the page fontsize (or 11px).

I think it may be important enough to include it in both pages. — Edokter (talk) — 20:07, 4 January 2014 (UTC)

Looks good. Bgwhite (talk) 22:11, 4 January 2014 (UTC)

That's a good summary of the conclusions of several discussions that I remember, so I'd be in favour of adding that guidance to editors. I'd put it in both pages with a hidden comment on each pointing to the other page to help future synchronisation. --RexxS (talk) 05:04, 5 January 2014 (UTC)

As I said at Wikipedia_talk:Manual_of_Style/Text_formatting#Font_size, talking to editors about point sizes and pixel densities is pointless. Just provide guideance about what to do or not do in wiki source. Dicklyon (talk) 05:31, 5 January 2014 (UTC)

Is "Avoid using smaller font sizes in elements that already use a smaller font size" not enough? I could add a ref explaining 11px, or add an image to illustrate. But the core is already explained in that sentence. — Edokter (talk) — 10:57, 5 January 2014 (UTC)

a good example of this problem can be found here. Frietjes (talk) 21:11, 6 January 2014 (UTC)

Seeing that has no objections, and apparently has been discussed before, I'm addin git to both pages. — Edokter (talk) — 21:40, 6 January 2014 (UTC)

No objections? Why are you ignoring mine? Dicklyon (talk) 03:41, 7 January 2014 (UTC)

Was the objection to the inclusion of terms like "85% of the page fontsize" and "11px"? There are plenty of editors who understand what that means and could make good use of it. The guidance would be incomplete without a summary of what editors thought was an acceptable minimum size. Perhaps there's an article somewhere explaining those terms that we could link to? --RexxS (talk) 04:42, 7 January 2014 (UTC)

"85% of the page fontsize" should be mentioned, but not things like 96dpi. It does give a good limit of what is too small. It also gives a good limit for the Wikilawyers. I've argued over 65% being too small, accessibility page is a MOS page and my favourite, the examples given in the heading section do apply to them. Without a lower limit, it will be hard to tell someone that their text is too small.

However, 11px probably shouldn't be mentioned. WP:FONTSIZE and W3C's Accessibility Guidelines say not to use px, but instead a percentage (% or em). It makes text scale better when someone resizes the web page, especially on older versions of IE. Bgwhite (talk) 07:07, 7 January 2014 (UTC)

I understand perfectly well what 11px and 85% and 96 dpi mean, but have little or no idea how they relate to the wiki markup language. It would be better to point out what the small template does, and say if that's the limit, and not to use it in already-small contexts, or something like that in terms of wiki markup. Dicklyon (talk) 06:46, 7 January 2014 (UTC)

Good point. Marriage both statements to something like, "85% of the page fontsize, which is what the <small> tag and the {{small}} template reduces text by." Bgwhite (talk) 07:17, 7 January 2014 (UTC)

Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections. The {{small}} template (or the <small>...</small> HTML tag) produces a font-size of 85% of its surrounding text. The resulting font size should not drop below 85% of the page fontsize: Text should never appear smaller then this.

— Edokter (talk) — 12:08, 7 January 2014 (UTC)

Braille

I've created quite a few articles on braille, using either Unicode or images. It seems rather ridiculous that the blind can't read them because braille readers can't process Unicode braille. I wouldn't mind adding brackets or something to the braille so that the blind could distinguish between linear and braille script in the articles, but how do you make the braille itself accessible? Or do we simply need to wait for braille displays to catch up? (This is also a problem elsewhere; if you email a blind person in braille, they can't read it.) — kwami (talk) 19:43, 7 January 2014 (UTC)

This links might be helpful.

• http://www.dmoz.org/search?q=braille+readers+computers
• http://search.botw.org/search?q=braille%20readers%20computers
• http://search.yahoo.com/search?p=braille+readers+computers&fr=

—Wavelength (talk) 20:07, 7 January 2014 (UTC)

Thanks, but I was hoping this had been addressed on WP, so we'd have some guidelines to follow. Because I don't have a braille reader to test things out on, I seriously doubt I'll be able to figure s.t. out that won't be full of bugs. And, frankly, if this isn't important enough to the blind community for people to have come up with something, I have other things to spend my time on. — kwami (talk) 20:14, 7 January 2014 (UTC)

There might be something useful in these search results for braille in the "Wikipedia" namespace. If not, then you can make a note on your calendar for similar inquiries each year.

—Wavelength (talk) 20:38, 7 January 2014 (UTC)

This talk page has 173 watchers and has been viewed 63 times in the last 30 days. You might have more success at Wikipedia:Village pump (technical), which has 2,611 watchers and has been viewed 13,072 times in the last 30 days. Also, I know of one totally blind Wikipedian, User:Graham87, and he might know of others.

—Wavelength (talk) 03:22, 8 January 2014 (UTC)

{{Braille cell}} is accessible withscreen readers because the dot patterns are in the alt text. Blind people never use the Braille Unicode points; they use Braille ASCII to get a Braille display to show whichever dot combinations are needed. Graham87 04:56, 8 January 2014 (UTC)

Accessible exponentiation

Hi.

How can we have exponentiation in an accessible manner? i.e. in a manner that screen readers read 2⁸ as "two power eight" instead of "twenty eight"?

Best regards,
Codename Lisa (talk) 13:58, 17 January 2014 (UTC)

How about <math>2^8</math> which renders as $2^{8}$, an image with alt text "2^8"? It obviously depends on the context whether that is an acceptable solution, but 2⁸ ( => 2⁸) is never going to be a solution; semantically it's 28 and you're relying on a visual artifact (superscript) to convey information - that is bound to cause problems somewhere or other. --RexxS (talk) 16:58, 17 January 2014 (UTC)

As in the previous discussion ("Braille"), this question might be answered by User:Graham87.

—Wavelength (talk) 17:14, 17 January 2014 (UTC)

JAWS reads it as 2 superscript 8 end superscript, which is good enough; I don't think other screen readers could process it properly. The "math" code is even better, accessibility-wise, but if there's a compelling reason not to use it, it shouldn't be used. Graham87 08:16, 18 January 2014 (UTC)

An Example of Very Bad Contrast

I've found a page titled DUKEDOM OF GRAFTON which has severe contrast issues. The colours are set using <body text="#FF0000" bgcolor="#666633" vlink="#800080" alink="#000000">. In case you can't get to the page, and don't know what that HTML tag does, it means that  plain text is coloured like this , for a contrast ratio of 1.49;  unvisited links are coloured like this , for a contrast ratio of 1.57;  active links are coloured like this , for a contrast ratio of 3.51; and  visited links are coloured like this , for a contrast ratio of 1.58. Perhaps we should use it as An Example of Very Bad Contrast? --Redrose64 (talk) 20:44, 23 January 2014 (UTC)

New proposal for toolbar redesign

There's a new proposal to re-design MediaWiki's toolbar, code-named Winter; comments about it are welcome at the proposal's talk page. Here is a prototype; I have already raised a few accessibility concerns about it. Graham87 10:30, 28 January 2014 (UTC)

Access question for a list

Someone has just gone through Arthur C. Clarke Award, a featured list, to denote the winners with a blue ribbon icon (), rather than with a * character like it was before. (The colored backgrounds have always been there in addition to the mark). Is this sort of marking acceptable from an ACCESS perspective? --PresN 18:20, 19 March 2014 (UTC)

No, at least not without a proper alt attribute; and probably not at all. MOS:ICON also applies. I've reverted for now. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 19 March 2014 (UTC)

I've modified {{Blue ribbon}} to allow an |alt= parameter and set default alt text, so it should be more accessible now. Unfortunately the icon is GPL and requires attribution, so we can't suppress the link.

MOS:ICON notwithstanding, I would no longer have concerns about its use in lists like Arthur C. Clarke Award as long as a sensible alt text (like |alt=winner) was supplied for every occurrence. I wouldn't bother re-reverting though! Cheers --RexxS (talk) 20:06, 19 March 2014 (UTC)

Wikipedia:Administrators' noticeboard/Header

Would someone please look at Wikipedia:Administrators' noticeboard/Header, specifically the "Are you in the right place?" section? I'm not certain, but I believe that it's a table of one column and sixteen rows, each cell of which contains a one-item list. If I'm right about how that template's working, then we really ought to simplify it. WhatamIdoing (talk) 16:53, 1 March 2014 (UTC)

Actually, the "Are you in the right place?" section is a table of 33 rows, 16 of which are empty rows 2px high. There are indeed 16 separate unordered lists in 16 of the other rows. I'll take an axe to the 33 rows and 16 lists, but looking at trying to clean the page up beyond that is causing me to lose the will to live. --RexxS (talk) 18:33, 1 March 2014 (UTC)

Thanks. That looks much better. WhatamIdoing (talk) 20:56, 19 March 2014 (UTC)

maps in templates

I attempted to add alt-text support for the map at {{infobox language family}} ("map" or "map2" and "mapalt" or "mapalt2"). I don't know what behaviour to expect. Is it working correctly? — kwami (talk) 20:14, 25 March 2014 (UTC)

Not quite. If you have popups enabled you can mouseover and read any alt text present. The alt text was showing as {{{mapalt}}} literally in a page where |mapalt had not been set. When that happens, you need to code it in the template as {{{mapalt|}}}. The pipe character can be read as "or default to". In other words if mapalt isn't supplied, it then returns what's to the right of the pipe - i.e. null in this case. I've made a tiny amendment to the template to insert the pipe character to {{{mapalt}}} and {{{mapalt2}}}. If you purge your browser you can see that in e.g. Austroasiatic languages there is no alt text, but in Germanic languages (where I've added |mapalt to the infobox) the alt text is displaying as expected. --RexxS (talk) 20:51, 25 March 2014 (UTC)

Background colours on templates

Please see Wikipedia talk:WikiProject Accessibility#Background colours on templates for a discussion on the use of background colours in templates (such as those used to mark closed discussions) which can cause accessibility issues when various text colours are used in the discussion. It is suggested that the use of such background colours should be avoided and that this may be introduced as a guideline or even a policy. —sroc 💬 06:49, 21 April 2014 (UTC)

Discussion

Though this might not be directly related if anyone wishes to weigh in on this discussion to improve accessibility at Template:Infobox album please see the discussion here Template_talk:Infobox_album#Consistancy. → Lil-℧niquԐ 1 - { Talk } - 22:02, 30 April 2014 (UTC)

Minimum font size

Regarding this recent edit and the corresponding one at MOS:FONTSIZE, please see Wikipedia talk:Signatures#On the topic of "Appearance and color" and line-height, and post comments there. --Redrose64 (talk) 20:25, 26 June 2014 (UTC)

Identical section headings

I thought that Wikipedia:Manual of Style/Accessibility#Headings (or MOS:HEAD?) used to say that having multiple, identical section headings was an accessibility issue. Is that no longer the case? WhatamIdoing (talk) 22:51, 27 July 2014 (UTC)

I don't recall that being an accessibility issue, but it's a bad idea for other reasons, as you probably know. Graham87 02:11, 28 July 2014 (UTC)

Using images as list bullet points

can someone look at the horizontal list in Trawniki men? I tried to change it to use actual list markup, rather than images as bullet points, but was reverted. is there a different method that I am not considering? I will start a thread on the talk page as well. Frietjes (talk) 14:12, 9 August 2014 (UTC)

a related issue with the TOC in Template:NRHP in Kentucky by county. Frietjes (talk) 14:42, 11 August 2014 (UTC)

I've commented, but it may need more eyes. The problem, as usual, is that editors think that if it looks ok to them, it doesn't matter about inconveniencing screen reader users. --RexxS (talk) 20:06, 11 August 2014 (UTC)

I've commented too. If you want to experience what screen readers go thru, installing free ChromeVox is helpful. Pressing <insert> twice activates screen reader movement. Asking Graham, with his industry standard JAWS software, is still the "word" when it comes to screen readers. Bgwhite (talk) 20:57, 11 August 2014 (UTC)

Feedback request (WPTC track maps)

A discussion pertaining to WP:COLOR is taking place at Wikipedia talk:WikiProject Tropical cyclones/Tracks#Wikipedia:Manual of Style/Accessibility#Color compliance. Feedback from knowledgeable or interested editors is welcome. -- Netoholic @ 02:00, 15 August 2014 (UTC)

I answered on the talk page. Bgwhite (talk) 05:14, 15 August 2014 (UTC)

Using "lang-x" template or simple wikilinking and formatting

Template:lang-de-AT is used in only Austrian Empire. Because no other pages use it, I'm torn between proposing deletion and leaving it alone for several years. I tried to replace the template with simple formatting, but someone reverted it and cited this guidelines as a reason. Shall we follow this guideline, or shall we consider usefulness and effectiveness of the template? --George Ho (talk) 23:40, 14 August 2014 (UTC)

The template should be left alone. Graham87 04:44, 15 August 2014 (UTC)

In other word, do not nominate as TFD? --George Ho (talk) 05:16, 15 August 2014 (UTC)

George Ho Graham Yea, keep the template and do not nominate as TfD. This is also a web standards question. Information about language codes and the web can be found at at w3.org. In short, de is the language tag. AT is valid region tag, therefore de-AT is valid. de-CH is also valid for German in Switzerland, but no template yet, so be very quite or one will be created. Bgwhite (talk) 05:31, 15 August 2014 (UTC)

The external link is dead; do you mean list of obsolete codes or this one? --George Ho (talk) 05:57, 15 August 2014 (UTC)

George Ho, link isn't dead, but my brain is for screwing up the link. Correct links is: http://www.w3.org/International/articles/language-tags/ Information for the article comes from RFC 5646, which is the current standard of "Tags for the Identification of Languages".

The list of obsolete codes (ISO 639) were superseded by ISO 639-1, ISO 639-1 and ISO 639-1. They are only for saying what 2 or 3 letter code that goes with what languages. For example, en for ISO 639-1 and eng for ISO 639-2. Same goes for your other link, so they are not applicable in this situation. Bgwhite (talk) 06:31, 15 August 2014 (UTC)

Which ones are Austrian, and do you know who types Austrian German? --George Ho (talk) 06:59, 15 August 2014 (UTC)

It is confusing. Took me several times of reading to understand (I hope). In the w3.org page, if you skip down until to the "The region subtag" section. It is about 60% the way down the text. There, they give an example of how these codes are constructed and mention AT. They also mention de-CH in the article, but I also saw that one elsewhere. Bgwhite (talk) 08:33, 15 August 2014 (UTC)

This still doesn't excuse the template's infrequency. I wonder if editors consider using this template, even when they may be aware of the phrase "Austrian German" and the regional language itself. --George Ho (talk) 08:44, 15 August 2014 (UTC)

Sorry, I don't have answers for your questions. I can understand the tag being relatively infrequent as it would only be used in a historical context. But, to its current use, I don't have an answer. For your second question, probably best asked at TfD or by some German editors. I did look on the German Wikipedia, they have six lang type templates for German. Vorlage:DeS (German), Vorlage:GswS-ch (German-Swiss), Vorlage:BarS (Bavarian) and three for old versions of German. No Austrian (that I could tell). Kategorie:Vorlage:Fremdsprachenunterstützung is the category for lang templates. Bgwhite (talk) 17:10, 15 August 2014 (UTC)

Templates in a series like lang-* are often not utilized very often while others in the same series are used constantly. The less frequently needed ones are there for completeness (both for user and automated tool expectation/need). There is no principle that a template must be frequently used to be useful. A template doesn't have to make excuses for how often it's needed. WP:DROPTHESTICK.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:08, 19 August 2014 (UTC)

See also

FYI

 – Pointer to relevant discussions elsewhere

George Ho has nominated several {{Lang-xx-YY}} templates for deletion, despite being advised against doing so above. They are grouped together near the top of Wikipedia:Templates for discussion/Log/2014 August 13. Some respondents there have made accessibility (e.g. screen reader) arguments regarding such templates, so participants here may be interested in those TfDs, pro or con.

See also: Ho raised related issues in a number of other forums (most of these deal with {{lang-xx-YY}} templates in particular, while the one at WT:NOT is more general):

• Wikipedia talk:What Wikipedia is not#"Wikipedia is not a technocracy"?
• Wikipedia:Village pump (technical)/Archive 132#Template:lang-de/sandbox
• Template talk:Lang-de#template:lang-de-AT

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:08, 19 August 2014 (UTC)

Alternative text for video and audio

There is no guideline to add alt text, so I propose to add the text to an accessibility icon. Examples:

Fez trial gameplay, demonstrating the rotation mechanic and game objectives

"Trail", a medley by Disasterpeace from the Fez soundtrack remix album FZ: Side Z

84.127.80.114 (talk) 12:23, 15 September 2014 (UTC)

English translations of Homer

any advice/help in cleaning up English translations of Homer is welcome. the lack of section headings is crazy, and the fact that the highest level table headings is all the way at the top of the article is also a mess. also, the width of the article is impossible on a narrow screen, not to mention the massive number of small tags. thank you. Frietjes (talk) 14:16, 4 October 2014 (UTC)

CSS aural styles inline

Is there much/any support for these in real screen readers? I'm wondering if, for example, our code layout templates should be using style="speak-punctuation: code;". Also, a <dt> template like {{Term}} maybe should be using style="richness: 75;" and perhaps a slight pause-before and pause-after. Would such tweaks actually be helpful?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:21, 30 October 2014 (UTC)

Not really, except for Emacspeak. Graham87 03:11, 30 October 2014 (UTC)

Unicode vs. marked-up ASCII equivalents (and HTML and entity codes)

I'd be interested in the accessibility arguments pro and con regarding:

• E=MC² (with Unicode character for superscript-2), E=MC² (with HTML code for same character), E=MC² (with character entity code for same character), E=MC{{sup|2}} (template), and E=MC<sup>2</sup> (the underlying markup behind the template, using HTML superscript). These render respectively as "E=MC²", "E=MC²", "E=MC²", "E=MC²", and "E=MC²".
• 1⅔ (with Unicode two-thirds character), 1⅔ (with HTML code for same character), {{frac|1|2|3}} (commonly used template), {{sfrac|1|2|3}} (alternative template), 1<sup>2</sup>&frasl;<sub>3</sub> (the underlying markup behind both templates, using HTML superscript and subscript markup, and the character entity code for fraction-slash), 1<sup>2</sup>⁄<sub>3</sub> (same but with Unicode fraction-slash), 1<sup>2</sup>&#8260;<sub>3</sub> (same but with HTML code for the fraction-slash), plain-text 1 2/3, and plain-text with thin-space 1 2/3. These render respectively as "1⅔", "1⅔", "1+2⁄3", "⁠1+2/3⁠", "1²⁄₃", "1²⁄₃", "1²⁄₃", "1 2/3", and "1 2/3". [The form "1-2/3" is sometimes encountered, but too easy to interpret as "1 minus 2/3", because the hyphen (-) is commonly used as a stand-in for the proper minus character (−, not distinguishable from hyphen in most fonts), and has been intended to serve double-duty since the dawn of computing.]

My general impression is that the Unicode characters can often be problematic, their HTML and entity code equivalents a little less so (mainly from an OS and browser support, not accessibility, point of view).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:22, 20 October 2014 (UTC)

As the guideline says, any character outside Latin-1 is highly problematic for screen readers. So your superscript character example was fine while your fraction one was not. Graham87 12:57, 20 October 2014 (UTC)

I think you missed an important aspect, editing. For the general editor, Unicode and HTML code would be harder to understand. Even the technical literate editor doesn't know what all the codes mean and would have to view the rendered page to know what it represents. For screen readers, listening to &#178; spelled out would be way harder to understand than hearing <sup>2</sup>. Bgwhite (talk) 21:57, 20 October 2014 (UTC)

We're supposed to use "Show preview" before saving non-trivial changes anyway, so "have to view the rendered page" is already an assumed step. It does seem at this point extremely odd that no major screen readers support Unicode, even common parts of it. Is this expected to change any time soon? One would think an open source project would be tackling this by now. Anyway, thanks for the replies. This confirms some of what I'd been expecting. Just to clarify, there's really no accessibility difference between Unicode and the &-codes from a reader perspective (they're both bad for screen readers if the character represented isn't in ISO Latin-1's character set), other than in editing mode the &-code version will be read out in a way that a sight-impared editor can tell what it is? This would seem to indicate that when we must use such a character, that it should be encoded, not given as bare Unicode. Exactly the opposite is the current general practice.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:03, 30 October 2014 (UTC)

I highly doubt that anything will change on this front in the foreseeable future. The main problem is the memory required to store the spoken representations of Unicode characters ... not to mention Braille, which only has 255 combinations of dots to play with. The only times Unicode characters should really be used in the edit window in articles directly are when writing text in other languages and when writing IPA; using numerical character references in these cases would be extraordinarily inconvenient for editors. If a screen reader user really needs to distinguish between Unicode characters, they can figure oute the code point of a character of interest. Graham87 03:29, 30 October 2014 (UTC)

So, should we not be advocating the use of numeric character references for other cases, like em dashes, etc.?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:17, 30 October 2014 (UTC)

Ah, I forgot about Windows-1252, which screen readers will be able to handle fine (at least the em and en dashes which are present in that character set), so I've clarified the text a bit. Using HTML entities for those characters would clutter up the edit window, IMO. Graham87 14:56, 30 October 2014 (UTC)

Animated images

am I the only one who finds this excessive? Frietjes (talk) 20:38, 7 November 2014 (UTC)

It seems pretty but utterly useless. I took a look at it using Fangs Screen Reader Emulator. I don't read Arabic, but I doubt anyone who does could interpret it as fast as it is rolling. The image has no alt text, but the names are linked below. I don't see this as an accessibility issue though. --  Gadget850 ^talk 20:52, 7 November 2014 (UTC)

Oh dear, we have multiple discussions on this. Wikipedia talk:Manual of Style/Images#Animated images in sidebar templates is older. --Redrose64 (talk) 21:44, 7 November 2014 (UTC)

actually the oldest is Template talk:The Fourteen Infallible. Frietjes (talk) 21:48, 7 November 2014 (UTC)

FLC table question

At the List of Seattle bridges FLC, a question occurred to me as I was reviewing it: in List of Seattle bridges the table is using bold and/or italics to call out if a bridge is a national/city landmark. Does that work for screen readers, or does it need to be a dagger/* after the year instead? --PresN 03:09, 20 December 2014 (UTC)

Bold/italics would work, but the use of "*"/{{dagger}} would be better because it would be more easily recognizable (screen readers don't automatically read out formatting changes unless instructed to do so). Graham87 03:28, 20 December 2014 (UTC)

List marker types

I've reverted the bold addition of the sentence "Likewise, do not switch between list marker types (e.g. asterisks and colons), unless embedding lists starting at the highest level." partly because it was not discussed beforehand, partly because the last clause is ambiguous. --Redrose64 (talk) 14:43, 6 January 2015 (UTC)

For what it's worth, I'd approve of a change like that. I think the last part of the sentence refers to nesting lists; for example, using "*" and "*:" as the first and second levels, respectively, rather than "*" and "::". Graham87 14:55, 6 January 2015 (UTC)

[ec] If you find the wording ambiguous, please feel free to improve it, but there is no requirement to discuss edits before they are made (WP:BOLD and WP:DNRNC refer). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:56, 6 January 2015 (UTC)

There was also no reason to revert me once I had started this thread (WP:BRD refers). You were WP:BOLD, I don't dispute that - I even acknowledged it early in my post above. I do dispute your call of WP:DNRNC because I didn't 'revert due solely to "no consensus"', see my post above. I didn't say so at the time, but I had noticed that you made your original edit six minutes after making this comment, which since WP:LISTGAP previously said nothing at all about "using asterisks below asterisks, and colons below colons", seems like altering the rules to suit your own viewpoint. TfD is a hostile place: please don't make it more so. Now, when it comes to list markup, I'm all in favour of accessibility - you will often find me removing blank lines in the middle of indented threads (as here) - but I don't see why a TfD discussion cannot be marked up as follows:

*'''Keep''' because etc.
*'''Delete''' because etc.
*:Comment on vote
*::Comment on comment
*'''Merge''' with X because etc.

This keeps the main list - a list of !votes each as a bullet - as a single three-item list; it has a sublist (which itself has a sublist) that although of a different type does not terminate and restart the main list. Graham87, are there accessibility issues with a discussion formed like that? --Redrose64 (talk) 16:23, 6 January 2015 (UTC)

There was no reason for you to revert me other than "discuss before adding", which means there was no reason for you to revert me.

The wording you removed specifically allows for nesting such as in your example ("embedding lists starting at the highest level"). The problem addressed is the broken nesting of lists, such as:

*'''Keep''' because etc.
*'''Delete''' because etc.
**Comment on vote
:::Comment on comment
*'''Merge''' with X because etc.

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 6 January 2015 (UTC)

examples of layout tables

The link to the data table tutorial is useful, but there's no such link for layout tables. Do any examples exist anywhere? Xaxafrad (talk) 07:27, 10 January 2015 (UTC)

Xaxafrad : Hi! We do not currently have a tutorial or examples of best practices for layout tables. But it is a very good suggestion. If anyone is interrested in making a layout table tutorial please go ahead ! :-) Dodoïste (talk) 10:29, 20 January 2015 (UTC)

Tiny ping

The accessibility of {{Tiny ping}} is being discussed. Please make your views known there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:37, 31 January 2015 (UTC)

Imminent MediaWiki feature that will impact accessibility for screen reader users

Please see T18691 Section headings should have some clickable anchor for passing links, particularly my comment there. Graham87 15:05, 1 March 2015 (UTC)

@Graham87: On that task, the earliest dated comment that is visible for me is by Edokter and shows the datestamp "Mon, Feb 2, 9:22 AM". Judging by the task number, there must have been earlier comments, over several years; yet there is no indication on how these might be viewed, nor when the task was originally raised. Adjacent tasks phab:T18690 and phab:T18692 were created Dec 17 2008, 4:05 PM and Dec 17 2008, 9:36 PM respectively, so phab:T18691 was almost certainly filed on 17 December 2008 - so more than six years worth of comments are inaccessible. I had earlier filed T89690: Missing task creation info to cover a related issue, but that was closed as "invalid", for reasons that I'm trying to understand. To me, the existence of hidden text with no clear means for showing that text is itself an accessibility issue, so if project members could add their thoughts to that task, I would be grateful. --Redrose64 (talk) 10:29, 2 March 2015 (UTC)

I see the same problem Redrose, file phab:T91381 about it, because whatever the reason it, that's not acceptable. Sorry I missed this change Graham87, but at least it's given a bit more attention again to fixing the edit section link problem as well. —TheDJ (talk • contribs) 09:23, 3 March 2015 (UTC)

{{paragraph break}}

@Graham87, Redrose64, Plastikspork, and Frietjes: I add {{paragraph break}} into articles where <p> is used inside footnotes. It will get removed because of "no consensus", even though the template says this is for accessibility reasons. If the template is important for accessibility, can this be added to Accessibility MOS page? Bgwhite (talk) 23:03, 9 May 2015 (UTC)

Shall we notify RexxS too? --Redrose64 (talk) 23:07, 9 May 2015 (UTC)

I saw a discussion on this issue a while ago - I think it was the one at Template talk:Paragraph break. Essentially you want to generate a visual break to start a new line without creating a nuisance for screen readers, and the template {{paragraph break}} does this just fine, and better than a raw <p> tag. Personally I would have named it Template:Visual break, to show it's got nothing to do with paragraphs, but that's just me. Naturally, I'd support the use of this template over raw html that carries unintended semantics with it, and I'd support adding it to MOS:ACCESS. --RexxS (talk) 23:19, 9 May 2015 (UTC)

Bgwhite, it would have been courteous to ping me. RexxS, the issue is that within ref tags, with bundled references, you need <p> for a paragraph break. In articles with a lot of references, adding the paragraph-break template would be a nuisance and would slow down load time if there were hundreds of them. Bgwhite and Magioladitis keeps removing the p tags, and are quite aggressive about it. Also, the paragraph-break template apparently causes formatting problems elsewhere for translations. Pinging Doc James who has raised the translation issue. Sarah (SV) ^(talk) 00:35, 10 May 2015 (UTC)

User:Graham87 appears to have a solution here [3]. What I oppose is the use of more templates that are not compatible between Wikipedias. Doc James (talk · contribs · email) 00:47, 10 May 2015 (UTC)

Graham suggested closing the p tags. That would be preferable to a template. Sarah (SV) ^(talk) 00:51, 10 May 2015 (UTC)

{{crlf}} would do the same thing. -- Gadget850 ^talk 01:01, 10 May 2015 (UTC)

(edit conflict) @SlimVirgin: References are rendered as lists in Mediawiki software and each reference is marked up with a <li>...</li> element; they are not semantically paragraphs. As far as a sighted editor is concerned, bundled references display just as well using <div></div> to force a new visual line as they would using <p>, so for the sighted, it shouldn't really matter which is used. I suspect though that a screen reader user might be initially confused by hearing a new paragraph announced for each bundled reference - I'd defer to Graham87 on how annoying or confusing that might be, but I'm guessing he'll tell us it's not a big deal. I do understand your concern about load times - if you recall, we discussed this about the cite templates before they were converted to Lua. However, the {{paragraph break}} template is extremely light-weight; I just previewed this page after adding 1,000 of the templates and the increase in load time was around a fifth of a second. So I wouldn't worry about load times in this case, as I doubt any article will be using enough bundled references for anyone to notice. James will always be concerned for translations when a new template is used on en-wp, and I share his concern when many our templates now depend on Lua modules, which complicates any attempt to port them to other languages. The good news here is that {{paragraph break}} is an extremely simple template and can be copied into any language Wikipedia without having to worry about internationalisation or dependencies. It is a slow process to improve the infrastructure of small Wikipedias - I struggle on occasion trying to help porting into the Welsh Wicipedia, without speaking Welsh! - but it's worthwhile in the long run. Has any of that been any use in providing some perspective on the issues? Cheers --RexxS (talk) 01:31, 10 May 2015 (UTC)

Hi RexxS, I use bundled refs, sometimes hundreds, so I'm not going to add that template each time, partly because of the nuisance factor, partly in case it slows down load time if repeated so often. I'm quite happy to close the p tag, which Graham suggested would resolve it. Sarah (SV) ^(talk) 01:38, 10 May 2015 (UTC)

@RexxS: Yeah, it's not that big a deal. Graham87 02:01, 10 May 2015 (UTC)

SlimVirgin Templates do not slow down load times for 99.9% of the people. If a person is not logged in, they get a cached version that has already been translated into one html page. If a person is logged in, the person gets a semi-cached version. The reason it is semi-cached is people can change their js and css settings. By semi-cached, I mean the parts that make up the page are cached, but it is put together when presented. Thus, your "slows down load time" is false.

@RexxS and Graham87: My original question is still in play. Is this important enough to add to the accessibility MOS page or not? By use the template or <p>...</p>. Bgwhite (talk) 06:17, 10 May 2015 (UTC)

I think it might help if you remember the problems we had at one time in editing big articles with massive numbers of citation templates. Sarah knows about the caching but her experience is coloured, I believe, by being unable to edit articles like Israel because loading and previewing times were of the order of minutes, not moments. Nevertheless, I would still support adding this to MOS:ACCESS; but my advice is to phrase it as a recommendation, rather than compulsory. In other words, IMHO, it's a feature that makes the Wikipedia experience nicer for the visually impaired, but doesn't rise to the level of being essential to their experience. Our biggest challenge, when dealing with technical issues, is to take less technically-knowledgeable editors along with us. We won't accomplish that by using the authority of our guidelines to force an issue. Personally I wouldn't hesitate to use {{paragraph break}} in preference to <p> for bundled references, but I don't believe it's such a vital issue that it's worth getting into conflict with other editors who, in all good-faith, don't accept that it's a net benefit. Life's too short. --RexxS (talk) 10:15, 10 May 2015 (UTC)

Thanks User:RexxS and User:Graham87. If the template was universally function in all languages I would no longer have concerns with its use. We have 287 languages plus incubator. Not that hard for the technically minded I am sure. Doc James (talk · contribs · email) 16:27, 10 May 2015 (UTC)

Indeed, James. I added it to the Swahili Wikipedia for you at sw:Kigezo:Paragraph break in less than a minute by following the redlink on your talk page. Please ping me if you need templates added to other language Wikipedias - it's often quicker than changing the article to be translated, and I'll soon tell you if it's not. Cheers --RexxS (talk) 17:04, 10 May 2015 (UTC)

RexxS, the backdrop is that I opened a discussion at the pump yesterday about AWB editing by Bgwhite and others. This is the response. I have no problem using this template on short articles, but it isn't reasonable to expect writers to add it hundreds of times, especially as Graham is saying it isn't a big deal. An article with 200 bundled footnotes might use it 600 times or more. Would it not make sense to fix whatever problem the p tag is causing (if any)? Sarah (SV) ^(talk) 17:38, 10 May 2015 (UTC)

Sarah (SV)... This has nothing to do with AWB editing or the pump discussion. AWB does not add the template, close with a </p> or remove the <p> in these cases. AWB will only remove <p> if it is in open text (ie not in a template or ref tags) and replace it with a blank line. I arrived at the page due to a broken bracket and a template variable being used... {{{variable|arg}}}. This was detected by CheckWiki. CheckWiki will detect <p> tags in open text, but does not check for <p> inside template or ref tags. I added {{Paragraph break}} manually days later after the AWB edit. Doc James removed them by saying get consensus. I then asked here if this was important enough to pursue.

Yes, it would make sense to fix the problem causing this issue. It took over eight years to fix this problem that was happening inside <blockquote> and {{quote}} type templates. It was only fixed because of VE. There is a T57674 ticket open on this current problem, that I commented on in 2013. When I took over maintenance of CheckWiki in ~2012 and removed CheckWiki detecting <p> where bugs were filed. I was only made aware of {{Paragraph break}} and also the disability reasons around 8 months ago. I do not actively look for this and only add the template when I see an "issue".

Having User:RexxS and/or Graham comment at T57674 would be helpful... They pull alot more weight. Stating the problem does cause a disability issue may help in getting it fixed sooner rather than later. Bgwhite (talk) 23:23, 10 May 2015 (UTC)

@Bgwhite: I'm about to do this; I'm going to use this message as a permalink. Graham87 01:25, 11 May 2015 (UTC)

@Bgwhite: I've also commented. But to be honest, fixing T57674 won't solve this issue for screen readers, because once it's fixed the html generated by a blank line in wikitext would be identical to the html <p>...</p> anyway. Semantically, bundled references ought to be a list (i.e. a nested list within the overall list of references), and the best way to mark them up would be to use an unbulleted list, {{ubl}}. That would probably be optimal for screen readers and would display acceptably for sighted users:

There are eight planets orbitng the sun in our solar system.

The sun is pretty big, but the moon is not so big. The sun is also quite hot.

The moon is most visible at night.

---

However, I don't suppose there's much chance of convincing people to switch to that, as it uses a template and the improvement for screen reader users would not be huge. --RexxS (talk) 14:04, 11 May 2015 (UTC)

Short animated gifs are no more accessible or less painful than long ones.

I don't understand the logic of enabling short ones without controls. In my experience, short ones can be worse, because they can flash more often. In my experience, the transition between the ending frame and the startying frame tends to be the painful part, the rest tends to just be distracting. 71.191.163.95 (talk) 20:33, 28 May 2015 (UTC)

I've tried to clarify the limit of five seconds of animation without controls. I've also added the requirement (in WCAG 2.0 Guideline 2.3) to limit the number of flashes allowed to three in any one second period. Does this help? --RexxS (talk) 22:23, 28 May 2015 (UTC)

Complex tables and Wikipedia

You are invited to join a discussion: Complex tables cannot be made accessible in Wikipedia and what to do about it Thisisnotatest (talk) 21:13, 7 June 2015 (UTC)

missing text

Under the "Bulleted vertical lists" section, at the end it states, "Do not separate list items with line breaks (<br>). Use one of the following methods." Problem is, it doesn't give any following methods. Bgwhite (talk) 23:37, 8 July 2015 (UTC)

The "following methods" are the sections following, i.e. Unbulleted vertical lists and Horizontal lists. In other words, the guideline advises replacing list items separated by <br> with: {{plainlist}}/{{unbulleted list}} if the list is to remain vertical; or consider {{flatlist}}/{{hlist}} if the list could be better rendered horizontally (in-line). I'll try to clarify that. Feel free to tweak if you can improve it --RexxS (talk) 00:32, 9 July 2015 (UTC)

Table summaries

FYI

 – Pointer to relevant discussion elsewhere

More input is sought at Wikipedia talk:WikiProject Accessibility#Expert review needed.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:36, 18 July 2015 (UTC)

Minor accessibility point discussion

I've made an accessibility argument (with regard to partially-visually-impaired users of GUI browsers with large font sizes), at MediaWiki talk:Common.css#Compensate for italic lean. Someone expressed skepticism about this, so it's probably best if some accessibility specialists have a look at it; it's possible I'm arguing for a distinction that doesn't need to be drawn.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:29, 29 July 2015 (UTC)

That discussion is still running. Some additional input would be useful.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:34, 11 August 2015 (UTC)

list gaps and over styling

any suggestions about what to do about [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] ... ? Frietjes (talk) 17:14, 26 July 2015 (UTC)

Just revert, especially when accessability is compromized. Wikipedia is not a styling playground. -- [[User:Edokter]] {{talk}} 17:28, 26 July 2015 (UTC)

Concur. If any of those tweaks has a real purpose it should be introduced, with consensus, individually. That looks like a spree of sandboxing.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:07, 27 July 2015 (UTC)

User:SMcCandlish, User:Edokter, it continues, some help with reverting would be appreciated. Frietjes (talk) 14:10, 11 August 2015 (UTC)

Has anybody approached Spartan7W? Alakzi (talk) 14:13, 11 August 2015 (UTC)

left messages on the respective talk pages. Frietjes (talk) 14:29, 11 August 2015 (UTC)

Thank you. Alakzi (talk) 14:37, 11 August 2015 (UTC)

Is there any reason nobody notified me ahead of time?@Frietjes: All these are on my watch list, I didn't see any talk messages. That would have been nice. Wikipedia is full of styling, almost all navboxes for universities and other institutions of higher learning have a colored style. Below linked are examples of these. They have been this way for a long time, with no objection. I see no injury done by styling, and the styling I used was not arbitrary, each was representative of the symbols of their respective jurisdictions.

Template:Ivy League, Template:Princeton, Template:USNA, Template:Patriot League navbox, Template:Yale, Template:Harvard Spartan7W § 14:42, 11 August 2015 (UTC)

none of those are related to U.S. politics or history. Frietjes (talk) 14:45, 11 August 2015 (UTC)

Please tell me what difference that makes. See Template:Popes, Template:Catholicism, and other Catholic-related templates. If there is a legitimate issue with my styling, that styling is also wrong. Spartan7W § 14:47, 11 August 2015 (UTC)

Mobile changes

Hi everyone, there are some proposed design changes for how the lead section of the article could be displayed on mobile web. The rationale and specifics of the change are elaborated on the mediawiki page. Please take a look and post your suggestions to the talk page. Whatamidoing (WMF) (talk) 17:24, 18 August 2015 (UTC)

Colour

I've reverted the rather WP:POINTy removal of the parenthetical wording from the colour-section's hatnote "This section is about the use of colors in articles (though the advice on contrast ratios is applicable more generally).". This, being part of WCAG, quite clealry applies to al web content, and there are incoming links from relevant discussions.

As noted at the head of the page:

The WMF's Non discrimination policy... "is approved by the Wikimedia Foundation Board of Trustees to apply to all Wikimedia projects. It may not be circumvented, eroded, or ignored by local policies". and says: "The Wikimedia Foundation prohibits discrimination against current or prospective users... on the basis of... disability".

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 20 September 2015 (UTC)

I reverted without seeing you had started a thread, though I did intend to start one anyway. It is not disruption to prove a point. This is a MOS page which is for the style of articles. If we were to keep inserting tidbits of global policy into the article-specific MOS it would become very unwieldy. I suggest you start a separate guideline if you want to globalise the sense of WP:COLOUR.

I will proceed to notify the relevant WikiProject of this discussion. BethNaught (talk) 15:58, 20 September 2015 (UTC)

This page and other parts of the MOS refer to other non-article matters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 20 September 2015 (UTC)

It makes little sense to split off color ratio policies that apply globally to another page when around 10 words here suffices. The measure preventing an unwieldly policy is common sense, and we should exercise it here. ~ Rob^Talk 16:18, 20 September 2015 (UTC)

The Manual of Style obviously does not apply only to article space. It is clear that templates must also conform to the MOS as they can produce output within articles, so require identical care in making them accessible. The same consideration applies exactly to the module namespace. In fact, since we expect all of our namespaces to be accessible to readers and editors with impairments, there is a clear case for applying sensible guidance on accessibility to all namespaces. Is there any reason why a user's talk page, for example, should display with a combination of foreground and background colours that would make it unreadable to someone with a common colour-blindness? --RexxS (talk) 16:34, 20 September 2015 (UTC)

One can start to split hairs on what is or isn't an article. Disambig pages are not articles, but reside in articles space. Templates show up in articles, but are not articles. In the end, shouldn't templates, disambig pages and talk pages be "content that anyone can use, edit, and distribute"? (quoted material from five pillars). MOS:ACCESS and specifically WP:COLOUR are one of the very few guidelines that apply on any Wikipedia page. I can't think of anything in WP:COLOUR that would not apply to talk pages, templates or help pages. Bgwhite (talk) 21:14, 22 September 2015 (UTC)

@BethNaught: There is nothing that requires MOS pages to apply just to articles as you seem to suggest. Since WP:ACCESS was merged into the MOS not so long ago, it has been accepted that global policy related to accessibility is documented here. What possible advantage could there be in re-creating a separate guidance page just to document global accessibility policy? --RexxS (talk) 03:30, 23 September 2015 (UTC)

OK. Given that the merge you mentioned appears to have happened in 2010, well before my time, I was not aware of it, but if that was a consensus decision then I'm entirely OK with this. As I say, the lead of WP:MOS does mention articles in particular; however, if the general understanding is that components can be global, I can live with that. I hope you understand that, given it's not my personal feeling on how the MOS should work, I wanted to check that Andy Mabbett's change actually reflected community consensus. Thanks all. BethNaught (talk) 06:43, 23 September 2015 (UTC)

@BethNaught: It's worth noting that WP:ACCESS is kind of a weird guideline because it derives its "authority" from a WMF policy that cannot be changed via local consensus. No matter what we write in the guideline itself or decide as a community, inaccessible colors cannot be used anywhere on the project where alternatives exist, as the WMF's non-discrimination policy is clear that we must make the site accessible to all potential readers whenever feasible. That policy is preceded by a statement that local consensus cannot override or erode it in any way. It's always tricky where we have WMF policies conflict with our preferred dispute resolution method, but this is an area where consensus has a much lesser role than it does elsewhere. ~ Rob^Talk 07:27, 23 September 2015 (UTC)

Referral to un-helpful category Image insertion templates

The Text section of this project page contains the following instruction:

Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is {{†}}; see Category:Image insertion templates for more.

However, Category:Image insertion templates appears not to have any content and in fact bears the message "Note: This category should be empty."

So how does one get a handy list of Image insertion templates? And would whoever knows please be so kind as to update that item? Or else fix Category:Image insertion templates so it shouldn't be empty and isn't, if that is the actual problem.

Thisisnotatest (talk) 06:40, 23 September 2015 (UTC)

Thanks for the note; I've fixed it. Graham87 14:59, 23 September 2015 (UTC)

Bold markup in pseudo-headings

It is a real improvement for screen readers when we replace pseudo-headings with real headings (usually ;Notes and ;Bibliography or similar in the ==References== section, when Harvard-style referencing is used). However editors often object to the cluttering up of the Table of Contents by these relatively 'trivial' level-3 headings. Often we can't use {{TOC limit}} because there are other, 'important', headings at level-3 that ought to be in the TOC. In such cases, the best compromise has been found to mark up the pseudo-headings as bold. This delivers the visual distinction that the editors crave, while creating a minimal annoyance to screen reader users (they can have announcing bold/italic/etc. turned off). That means the screen readers can't navigate directly to the sub-headers (nor can anyone else!) because they are not marked up as headers, which is sub-optimal, but it may be the best we can achieve when the article editor is determined to achieve a particular visual appearance. --RexxS (talk) 21:57, 26 September 2015 (UTC)

In such cases, it would be better to have {{TOC limit}} fixed, and retain the use of proper, accessible and semantic heading markup. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:59, 27 September 2015 (UTC)

Indeed it would be better. But the effort required to achieve that in the face of determined opposition makes the improvement not worth the pain involved. Life's too short. --RexxS (talk) 20:57, 27 September 2015 (UTC)

Layout table clarification

I believe a table such as

COL	Colonel	LT	Lieutenant	SGM	Sergeant-Major	CPL	Corporal
LTC	Lieutenant Colonel	1LT	First Lieutenant	4SG	Fourth Sergeant	PVT	Private
MAJ	Major	2LT	Second Lieutenant	SGT	Sergeant	QM	Quartermaster
CPT	Captain	CNT	Cornet	3CPL	Third Corporal	AQM	Assistant Quartermaster

straddles between being a data table (abbreviation and value) and a layout table (using multiple columns to save space). My reading is that this is not accessible, but it's not clear from the section on layout tables whether this is the case. Could someone clarify? Thisisnotatest (talk) 09:12, 26 September 2015 (UTC)

It's a layout table, so shouldn't be marked up with scopes as that will confuse screen readers - and they are meaningless in the way they are shown; e.g. 'Major' seems to be a row header for 'Second Lieutenant', which is nonsense. It's also a mess on mobile devices as there are eight fixed columns, so I'd recommend avoiding this sort of markup.

For this sort of common problem (multiple columns), you would be best using a template that simply allowed the content to flow inline, like this one I made as a demo:

COL

 

Colonel

LTC

 

Lieutenant Colonel

MAJ

 

Major

CPT

 

Captain

LT

 

Lieutenant

1LT

 

First Lieutenant

2LT

 

Second Lieutenant

CNT

 

Cornet

SGM

 

Sergeant-Major

4SG

 

Fourth Sergeant

SGT

 

Sergeant

3CPL

 

Third Corporal

CPL

 

Corporal

PVT

 

Private

QM

 

Quartermaster

AQM

 

Assistant Quartermaster

A screen reader would simply read those linearly - there's no real advantage in having a table when the data is in pairs. This kind of layout re-flows gracefully as you resize the window (try it!), and should be just as readable for a sighted visitor as the original table. Does that help? --RexxS (talk) 22:45, 26 September 2015 (UTC)

For the record, "Major" is not a row header – it's using the scope attribute on a td element, which is deprecated in HTML5. nyuszika7h (talk) 10:16, 27 September 2015 (UTC)

What would be the purpose of "scope", if it were used correctly? — Arthur Rubin (talk) 19:59, 27 September 2015 (UTC)

For td elements, there is really no point, as those are either headers improperly marked up as td, or normal data cells in which case scope should not be used at all. For headers, it's used to specify whether they're column or row headers, which is most useful if they are not in the first row or column, though being explicit is better, and scope="row" is also used for the plainrowheaders style on Wikipedia. nyuszika7h (talk) 20:16, 27 September 2015 (UTC)

@Nyuszika7H:, if you mark up any cell with scope (as is done with the Major cell) then a screen reader will usually treat it as a row header, regardless of what HTML5 says it is in theory. So yes, it is a row header as far as most screen readers are concerned and JAWS, for example, is likely to announce it as the row header for cells to the right of it when navigating in table layer mode. As usual, I'd recommend reading http://www.freedomscientific.com/Training/Surfs-up/Tables.htm to get an insight into what is happening. @Arthur Rubin: with modern screen readers the user can choose "table layer mode", which allows them to navigate from cell to cell in any direction, instead of being forced to read the entire table left-to-right, top-to-bottom (as used to happen). In that mode the user can have the column and row headers spoken before the data in the cell, e.g. going down the Category column at List of accolades received by The Artist (film) #Accolades, one might hear "Academy Award","Category","Best Picture"; then "Academy Award","Category","Best Director"; and so on. It's well explained in the link I gave above. However, older screen readers were inconsistent in how they would decide on the row header: some would simply use the first cell in the row, many others would override that if a different cell were marked up as <th>...</th>, and yet others would give preference to a cell marked as scope="row". Similar issues would affect column headers. So to maximise the chance of any particular screen reader using the cell we designate as the row/column header, we give the advice to mark up the column and row headers with both '!' and 'scope'. Redundancy never makes the issues worse and usually gives the desired result, even with older software. Hope that helps. --RexxS (talk) 21:32, 27 September 2015 (UTC)

So it looks like Jaws correctly handles scope markups. What about other readers? Anyway, thanks for the explanation on the included table; perhaps removing scope from that table is the best move? Thisisnotatest (talk) 05:19, 28 September 2015 (UTC)

Sadly there are far too many screen readers (and versions of the same reader) to give a general answer - you only have to look at List of screen readers to get an idea of what the range is. To date we haven't agreed as a community to only support a limited range (e.g. the most popular, or versions less that three years old), so my advice is to design for the worst case, so include using both '!' and 'scope' on all data tables, as described at WP:DTT. Layout tables definitely should not have cells marked as headers (see F46), so the original table should not have '!' or 'scope' markup. The other options would be to reformat the data into a data table with 2 columns and 16 rows (plus a header row for the columns such as "Abbreviation", "Meaning") (which would leave a lot of white space on a wide screen); or to make four separate data tables with proper headings and place them inside a layout table of 4 columns and 1 row (which would be horrible markup and would not work on small screens). --RexxS (talk) 20:04, 28 September 2015 (UTC)

Individual Engagement Grants

• m:Grants:IEG/Alt text tools
• m:Grants:IEG/Color blindness content checker

Apparently this is just a publicity contest where I'm penalized for not being able to write in English. Anyway, I'd like to make a Dab solver tool (+WP:DPL) for alt text. Automatic colorblindness is more uncertain (keep finding mistakes in papers), but we'd have something and hopefully more resources. — Dispenser 17:06, 27 September 2015 (UTC)

Dispenser. These are good ideas. But I'm afraid they might turn out to be much more complicated than they seem to be.

I've commented on alt text for example. Currently, most alt text that users write on Wikipedia is not great. Because it's a complicated issue that is also dependant on the mistakes of the MediaWiki software. Rather than aiming to increase the quantity of alt text, I think we should first try to improve quality and understanding. Dodoïste (talk) 14:42, 30 September 2015 (UTC)

Windows-1252 symbols

Wouldn't Windows-1252 symbols be unpronouncable to Mac or Unix screen readers? Would it be better to restrict non-imaged/non-templatized symbols to Latin-1? Thisisnotatest (talk) 21:43, 26 September 2015 (UTC)

Most symbols are skipped by a lot of screen readers. JAWS won't even read †, which is why we have {{dagger}}. I'd recommend restricting symbols to those that you can type directly from a keyboard. --RexxS (talk) 22:01, 26 September 2015 (UTC)

@RexxS: Thank you for the quick response. On Mac OS X that would include excluding characters that can be reached via option-key or option-shift-key.

Rather than explaining which characters can be used, I suggest just listing the okay characters (using the characters themselves) that don't need to be imaged. Then nobody has to figure it out. And screen-reader users can easily point out erroneous inclusions because they'll hear them. (And why does # (shift-3) have a template {{Hash-tag}}?)

I think it's good to say most symbols will be read as question marks by nearly all screen readers, but we need to not go into the technology (Latin-1, Windows-1252) on an MOS page and stick to what they are to do or not do, so it's unambiguous. Maybe a Details link for people who want more information. Or am I missing something?

Thisisnotatest (talk) 22:41, 26 September 2015 (UTC)

1. Some screen readers will just ignore some unknown characters, rather that speaking "question mark", so we really ought not to put the burden on screen-reader users to spot erroneous inclusions for us.

2. I agree that a list of good choices is sensible. That's [A-Z], [a-z], [0-9], [!£$%^&*()-=_+/@~#<>?\|{}] - have I missed any? A lot of the time, we use symbols in lists to mark a footnote; for those the choice is best kept to # * + $ and maybe one or two others.

3. The {{Hash-tag}} was created by a very keen editor in imitation of {{dagger}}, and I didn't have the heart to tell him that screen readers could cope with '#'. A secondary reason is that the image-symbols take alt text, and this may be better for screen-readers than having to wait till the end of the list/table to get the explanation for the symbol. A list of the players in a cricket team, for example, is nicer if we use {{†|alt=wicket keeper}} to mark the wicket keeper. It's sometimes good to use {{Hash-tag}} in a similar way. Cheers --RexxS (talk) 23:07, 26 September 2015 (UTC)

@RexxS: Thank you. Then I suggest replacing:

Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read.

1. Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
2. Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
3. Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).

with:

Many screen readers will read most special characters as a question mark or not at all.

1. Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
2. Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
3. Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
4. Safe symbols to use without a template are any of the following: !£$%^&*()-=_+/@~#<>?\|{} as well as A through Z, a through z, and 0 through 9.

Thisisnotatest (talk) 01:22, 27 September 2015 (UTC)

This sounds reasonable, I guess, but characters like the dagger are alright in isolation, just sometimes not when they're attached to text. Ditto with "–" and other characters. Graham87 07:31, 27 September 2015 (UTC)

My opinion is actually that that is totally unworkable and unacceptable. Use the proper characters where they are useful and appropriate. Don't do crazy workarounds for them 'just' for screenreader purposes. That is more likely to encourage browser/OS/screenreader vendors to catch up then anything else. The reason I say this, is that basically the above translates to: "screen reader accessibility requires a reduce symbol set". Which is dumb, because the world is about a lot more scripts than just latin script. By plugging these holes, we are doing the rest of the world/web a disservice, by pretending the world is 'prettier' then it actually is. Screenreaders should support all scripts (ideally) but definitely all symbols. They don't even have to do much work for that, the entire unicode table has simple accessible descriptions for every single symbol already. It's laziness and unwillingness of vendors that makes these parts of the web inaccessible, not us. I fully support the desire to make the web accessible for anyone, but I'm totally opposed to this kind workarounds. History has proven that it doesn't work for more than just the paltry 0.1% that editors (web and wiki alike) will get around to fixing after everything has been authored already. —TheDJ (talk • contribs) 21:47, 28 September 2015 (UTC)

But the replacement is at least better than what was there before ;) Remember that this is not just about screenreaders. Readability for any person is also accessibility, and something like transliteration fills that need just fine. But transliteration for the purpose of fixing the screenreader, seems misguided to me. —TheDJ (talk • contribs) 21:50, 28 September 2015 (UTC)

But even 0.1% of readers is still a massive number. Screen readers have been around for some time now and the incompatibilities have not yet been fixed. It is flawed reasoning to dismiss the impairments of so many people by blaming assistive technology for not being better. Don't forget that JAWS can cost around $1,000 and updating to the latest version can be beyond the finances of many - not least those reading our content from less developed countries, who may have to settle for older technology. We have a known problem and we have the means to ensure that the maximum number of impaired visitors can access our content by keeping the symbol set simple. It's no more difficult than asking editors to keep the content readable by non-specialised visitors. Nobody would advocate using complex jargon in an article because it would put pressure on the schools to educate students better. --RexxS (talk) 14:56, 30 September 2015 (UTC)

Ordinals and superscript

Visual Editor has decided that ordinals must be superscripted. I usually see a couple of non-VE edited articles a day using superscripts and today there were 20+ VE articles. Before I file a bug ticket only to have the ticket dumped on the backlog queue to never see the light of day again, I'd thought I'd add accessibility info. Maybe that would help fix the problem. Do screen readers have issues with superscripted ordinals..... 2nd vs 2^nd ? Bgwhite (talk) 06:38, 15 October 2015 (UTC)

I don't know of any screen readers that have problems with superscripts, but I'll ping @Graham87: to confirm. I'd be more concerned for older readers that the superscript css reduces the font size to 80%, which breaches our 85% minimum guideline at MOS:FONTSIZE, and that is 10.16px in monobook skin, which breaches the 11px minimum guideline there as well. I suppose I should also mention that MOS:ORDINAL, which is the agreed style for our articles, quite clearly states

• Ordinal suffixes suffixes (-st, -nd, -rd, -th) are not superscripted (123rd and 496th, not 123^rd nor 496^th).

--RexxS (talk) 18:29, 15 October 2015 (UTC)

Nope, it doesn't make a difference with screen readers. Graham87 02:43, 16 October 2015 (UTC)

@RexxS and Graham87: Thank you both. I'm aware of WP:ORDINAL as CheckWiki scans for these and I fix them. The problem is the MediaWiki developers don't care about bug reports. A group of us have identified over 30 issues with Visual Editor and Content Translator after we were encourage to do so at the last Hackathon in May. Both projects do not use the same Parsoid, so one has to report the same bug to both groups. VE group is more responsive to bug problems, Content Translator group just ignores us. You would think a bug where VE adds <nowiki> tags in refs (ie <ref><nowiki>{{cite web |.... }}</ref></nowiki> would be important to fix. Others bugs, such as Content Translator wikilinking dates, are a MOS issue on English Wikipedia and are not important. So, if the ordinal issue were accessibility rather than MOS, it might get fixed rather than be put on the backlog queue. Bgwhite (talk) 04:55, 16 October 2015 (UTC)

If an individual editor made such errors, persistently, after being advised not to, they'd be blocked, per WP:COMPETENCE, until they gave an undertaking to desist. Is there a comparable way we can gain the attention of those behind VE and CT? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:46, 16 October 2015 (UTC)

Andy That is exactly what Magioladitis says every week after he gets frustrated with VE and CX. I wish I knew of an answer. FYI... They use CX as the abbreviation for Content Translator.

I don't have a problem with people not fixing their edits with VE. VE is supposed to do things correctly. CX is an entirely different mess of fail. Majority of people using CX are new and/or don't understand English. This is the most current article done with CX. It's a lovely piece of crap. There is also this, with <cite> tags (not templates) and whatever [[Paris|P]]<nowiki/>aris and [[Rome|Rom]]<nowiki/>a is supposed to be. Bgwhite (talk) 21:08, 16 October 2015 (UTC)

Indentation

Wikipedia:Manual of Style/Mathematics#Using LaTeX markup recommends using association list formatting to fake a visual indentation for mathematics formulae. Do you all think that it's worth changing this (e.g., to something that provides the visual cue but uses {{indent}} or CSS formatting)? WhatamIdoing (talk) 18:26, 15 December 2015 (UTC)

Personally, I'd recommend using {{indent}} as it is a 'cleaner' implementation. No screen reader is going to be confused by spaces in the way that using a description list with a null term can turn into a nuisance for those users. Nevertheless, I expect screen reader users will be used to it by now. I'm rather more concerned with the recommendation in Wikipedia:Manual of Style/Mathematics #Alt text that "More complicated formulas, or formulas used in more technical articles, are often better off with the default alt text." I don't know what genius thought that up, but I fail to see who would be better off with the default alt text of "\int _{0}^{\infty }e^{-x^{2}}\,dx." (as used in the example in Wikipedia:Manual of Style/Mathematics #Using LaTeX markup) rather than something like "integral from 0 to infinity of e to the minus x-squared dx". I'm tempted to just remove that sentence. --RexxS (talk) 00:40, 16 December 2015 (UTC)

Maybe the alt text used to be better? I can't imagine anyone really proposing that reading out LaTeX code was a good idea. WhatamIdoing (talk) 18:47, 24 December 2015 (UTC)

It looks like <math display="block"> provides the indentation without adding odd spaces or list formatting. WhatamIdoing (talk) 18:49, 24 December 2015 (UTC)

Bot run for removing blank lines in list

I can create a list from dump files that show which articles have a blank line inside an unordered list. The list must be done in wikicode. AWB can fix the vast majority of these cases. AWB will only fix if the the blank line contains only a newline. Any spaces or tabs before the newline and AWB won't fix. Is this a good enough idea to get bot approval? I'm sure there will people who complain, so I'd like to get all my ducks in a row. Bgwhite (talk) 09:36, 24 December 2015 (UTC)

Sounds great to me. Thanks very much for helping out with this. Graham87 13:56, 24 December 2015 (UTC)

I would really love to have this done. I've been cleaning them up manually for years, and it doesn't seem to make a dent. May I recommend an explicit link to WP:ACCESS#Lists in the edit summary, since many people don't know about this issue?

Also, I'd like to see a bot that cleans up the use of semi-colons to make fake section headings (the last item in Help:List#Common mistakes). If the ;heading isn't followed by a :colon, then the semi-colon should be replaced by bold text. WhatamIdoing (talk) 19:01, 24 December 2015 (UTC)

I did a scan of 20% of the dump and there were 34,298 articles with a blank lines. I now can easily do scans for images in a list, fake headings made up of semi-colons and other variations. I think the images and fake headings will need to be fixed manually. Yes, I will be using an explicit link in the edit summary. When I moved TOCs to their proper spot for accessibility reasons, I did use explicit links. This still didn't stop the yelling, threats and being taken to ANI several times... main reason to get all the ducks in a row. Bgwhite (talk) 21:45, 24 December 2015 (UTC)

BRFA submitted at Wikipedia:Bots/Requests for approval/BG19bot 9 Bgwhite (talk) 23:57, 28 December 2015 (UTC)

Damned good idea.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  18:42, 19 February 2016 (UTC)

Two test pages

For your tinkering (and proving what it does to people who don't believe you) pleasure, I present:

• Wikipedia:Manual of Style/Accessibility/dl tests – How to [hopefully not] break <dl> description/definition/association lists.

• Wikipedia:Manual of Style/Accessibility/anchor tests – What happens, with what potential side effects, using a bunch of different ways to anchor in and near headings.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:46, 26 February 2016 (UTC)

role="presentation" for layout tables

The role attribute was whitelisted back in 2013, especially for use with layout tables (Phabricator T26583 and merge). I added a recommendation to use the role attribute, as an extra precaution against screen readers interpreting them as data tables. Sorry if this was overbold! Matt Fitzpatrick (talk) 07:02, 12 April 2016 (UTC)

Oh, it's about darned time.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:30, 15 April 2016 (UTC)

Pseudo-headings vs. non-indexed section header

On this page, it says "Do not make pseudo-headings using semicolon markup and try to avoid using bold markup." But at Help:Punctuation#Semicolon, it says "A leading semicolon ‹;›, in column 1 of a line, causes the line to be displayed as a bolded, non-indexed section header." What resolves the contradiction? Stevie is the man! ^{Talk • Work} 20:21, 8 April 2016 (UTC)

@Stevietheman: A leading semicolon makes the line a <dt> term inside a <dl> description list. MediaWiki's default CSS bolds <dt> elements, so to sighted users, ;XYZ resembles '''XYZ'''. To screen readers, though, yikes! Many, if not nearly all, screen reader users navigate pages by skipping from heading to heading, but <dl><dt>XYZ</dt></dl> isn't read or navigated like a heading, it's read and navigated as a list. Help:Punctuation should be changed; I'd consider this use of a semicolon in an article to be an accessibility error. Matt Fitzpatrick (talk) 10:54, 12 April 2016 (UTC)

It needs to be removed from the wiki code altogether if it causes problems like this. Or MediaWiki should be changed to format it in HTML differently. It's amazing to me that it has existed for so long and has such broad use for nobody to work on a fix for it. Stevie is the man! ^{Talk • Work} 13:22, 12 April 2016 (UTC)

Alternatively, we can just change the bad advice at Help:Punctuation #Semicolon, so there should be no further confusion. --RexxS (talk) 16:43, 12 April 2016 (UTC)

Why not a technical fix that renders ";" differently as well? After all, people are still going to use it based on long precedent and continued support in the code. Stevie is the man! ^{Talk • Work} 17:47, 12 April 2016 (UTC)

How else do you propose to include definition lists in wikicode? Any serious proposal requires that you show a sensible replacement; I can identify none. There is currently an existing Phabricator task to make it such that "when in a certain placement, ; acts in a certain way", but this produces inconsistency in expectation, and I suspect that the task will not be acted on as a result. Better instead simply to fix the use as you identify it, provide policy and guidelines for others to read if/when your change is reverted, and move on. --Izno (talk) 19:12, 12 April 2016 (UTC)

I'm not talking about definition lists; I'm talking about non-indexed section headers, as has been prescribed for many years in the Help. Policy/guideline changes are not a technical fix to something that is widely used. Try again. Stevie is the man! ^{Talk • Work} 19:18, 12 April 2016 (UTC)

If you're talking about semicolon wiki-markup, then you're talking about description lists. They are used correctly multiple times in every glossary article and in many other situations, so there's no chance of changing the semicolon to mean anything else. There are headers and elements which are not headers; there is no such thing as a "non-indexed section header", although you can limit the depth of header for which the MediaWiki software creates a table of contents entry by using {{toclimit}}. If a piece of markup is wrong, it doesn't matter how widely (ab)used it is, it's still wrong. Education is the "technical fix" for misuse of markup, widespread or otherwise. Is that clear enough for you? --RexxS (talk) 00:51, 15 April 2016 (UTC)

That's how Wikipedia's Help described the use of the semicolon before you changed it, and it has been understood and used that way for many years if not well over a decade. You can't say there is no such thing as something that Wikipedia's own help and long use of it contradicts. Stevie is the man! ^{Talk • Work} 11:48, 15 April 2016 (UTC)

Also, I still believe a technical fix is required for the reasons I already gave. Education doesn't fix the wide use of the semicolon as a heading, toclimit is an overly broad solution in many cases, and since there are likely many Wikipedians who will continue to insist on using the semicolon this way (and it's arguably reasonable), it should be formatted a different way so as to not cause any technical issues. Is that clear enough for you? Stevie is the man! ^{Talk • Work} 11:59, 15 April 2016 (UTC)

It's wrong. There is nothing more to say on the point. Fix the offending help page and move on. --Izno (talk) 11:55, 15 April 2016 (UTC)

It's not wrong to everyone who has been using it according to the Help for over a decade, and it was within reason. Fix the formatting of it. Stevie is the man! ^{Talk • Work} 12:01, 15 April 2016 (UTC)

You apparently took my comment as disparaging the work of those others (you included, I presume?). That would be an incorrect reading. Simply stop using it in that fashion; where you see it used like so, fix it (or don't--it's a volunteer wiki); and otherwise go about your merry wiki-life. --Izno (talk) 12:12, 15 April 2016 (UTC)

Did you bother to read the page or check the history that you so grandly describe as "Wikipedia's Help", Stevietheman? It's an essay written in 2012 and has no standing other than "the advice or opinions of one or more Wikipedia contributors". In fact, it warns you that "Essays are not Wikipedia policies or guidelines. Some essays represent widespread norms; others only represent minority viewpoints." Quite clearly, an essay that contradicts our Accessibility guidelines has no value at all. Education is the only way to fix the misuse of a semicolon in place of a heading. Which bit of "there's no chance of changing the semicolon to mean anything else" did you find too difficult to comprehend? --RexxS (talk) 22:44, 15 April 2016 (UTC)

I often have trouble comprehending an assertion that nothing can be done when it absolutely can be done. I'm funny that way.  :) The reality is that the Help backed up and common wiki habits established the semicolon for non-indexed section headings. I find it rather elitist to backhand it this easily. Of course I want our pages to be accessible, but I also want editors to not be told something they've been doing for over a decade is "wrong" when it's really not wrong -- it's just formatted in a shit manner by the software. I realize that I will not convince any of you of this position, but I've seen nothing so far to budge me. Stevie is the man! ^{Talk • Work} 23:39, 15 April 2016 (UTC)

People should not be using a semicolon to create bold pseudo-headings; it's list markup. People should not be using colons to create indents; it's list markup. If people want bold, they can use '''foo''' or <b>bar</b>. If they want strong emphasis they can use <strong>baz</strong> or {{strong|quux}}. If people want to indent something short, they can use {{in5}}; if they want to do a block indent, they can use {{block indent}}, and should not abuse block quotation markup for that. Talk pages are kind of a lost cause at this point, but we should use better formatting in articles.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:41, 16 April 2016 (UTC)

RfC on alignment of template headings

FYI

 – Pointer to relevant discussion elsewhere.

Please see Template talk:Collapse top#RfC: Heading centered or left by default?, for a discussion that would affect the default text-align of the headers/titles of various content-box templates.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:43, 19 April 2016 (UTC)

RFC on application of BADHEAD

Please comment at Talk:Glossary of video game terms#RfC: Replacing pseudo-headers. --Izno (talk) 12:03, 27 April 2016 (UTC)

Use of mirror-image placement to reverse position of flags and country names in side-by-side comparisons of national stats

FYI

 – Pointer to relevant discussion elsewhere.

Please comment at Template talk:FlagIOCathlete#Option to move flag. The discussion is about adding template parameters to enable displays like the following, which in the second column reverse the position of the flag and country, simply for the sake of a mirrored visual effect:

Jane Smith		United States	vs.	France		Jeanne Deaux
Xian Chen		China	vs.	Honduras		Juana Perez

There may (or may not) be information architecture, usability, and accessibility concerns with this.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:21, 7 June 2016 (UTC)

Decorative image attribution creates audible clutter

Where images requiring attribution are used in a decorative way, such as in Template:Portal bar where the images merely repeat the information in adjacent text, a conflict arises. The licensing requires a link, but best practice is empty alt text for decorative images and, by extension, no link. To help prevent irrelevant audible clutter interrupting the flow of text, I think the accessibility MoS should encourage the use of elements not requiring attribution (e.g. public domain images) for decorative use. Matt Fitzpatrick (talk) 23:16, 20 June 2016 (UTC)

I agree. --RexxS (talk) 23:47, 20 June 2016 (UTC)

Indeed. There's no need for screen reader users to know about them. Graham87 01:20, 21 June 2016 (UTC)

I "fourth" this proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:47, 3 July 2016 (UTC)

Noticeboard for discussion of images that may violate MOS?

A user raised a concern at Talk:Lightning that one of the images on the page, File:Lightnings sequence 2 animation.gif, may violate the MOS for accessibility, particularly MOS:ANIMATION. Where is the best place to get an opinion on whether there are too many flashes in that GIF? —C.Fred (talk) 23:51, 25 July 2016 (UTC)

How about WT:WCAG? --Redrose64 (talk) 11:04, 26 July 2016 (UTC)

See if File:Lightnings sequence 2 animation-wcag.gif is any better. I've commented at Talk:Lightning --RexxS (talk) 16:57, 26 July 2016 (UTC)

Use of Flatlist and Hlist in infoboxes

A discussion regarding the use of {{Flatlist}} or {{Hlist}} in various music infoboxes is ongoing at Template talk:Infobox album#Harmonization with other music templates. Comments regarding their benefit are welcome. —Ojorojo (talk) 13:25, 2 August 2016 (UTC)

MOS:LISTGAP question

MOS:LISTGAP says don't do this:

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

Is that the same as doing this?

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

An example of how this is used in TV articles is at Supergirl (TV series)#Cast and characters. --AussieLegend (✉) 11:39, 13 August 2016 (UTC)

Yep, exactly the same. I'd think a definition list would be betterfor that example. Graham87 15:14, 13 August 2016 (UTC)

(edit conflict) It's almost the same: you finish one sort of list and then start a different type. Here's the html generated by the first example you give:

<ul>
<li>Support. I like this idea. <a href="/wiki/User:Example" title="User:Example">User:Example</a></li>
</ul>
<dl>
<dd>
<dl>
<dd>Question: What do you like about it? <a href="/w/index.php?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd>
</dl>
</dd>
</dl>

and by the second:

<ul>
<li>Support. I like this idea. <a href="/wiki/User:Example" title="User:Example">User:Example</a>:</li>
</ul>
<dl>
<dd>Question: What do you like about it? <a href="/w/index.php?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd>
</dl>

What we should have is probably:

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

which results in:

<ul>
<li>Support. I like this idea. <a href="/wiki/User:Example" title="User:Example">User:Example</a>:
<dl>
<dd>Question: What do you like about it? <a href="/w/index.php?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd>
</dl>
</li>
</ul>

You don't notice much difference at one level of indent, but when it gets more than that, the unwinding of one list in order to start another gets noticeable. Have a look at the html from this:

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

<ul>
<li>
<ul>
<li>Support. I like this idea. <a href="/wiki/User:Example" title="User:Example">User:Example</a>:</li>
</ul>
</li>
</ul>
<dl>
<dd>
<dl>
<dd>Question: What do you like about it? <a href="/w/index.php?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd>
</dl>
</dd>
</dl>
<ul>
<li>
<ul>
<li>Oppose. I hate this idea. <a href="/wiki/User:Example3" title="User:Example3">User:Example3</a>:</li>
</ul>
</li>
</ul>
<dl>
<dd>
<dl>
<dd>Question: What do you hate about it? <a href="/w/index.php?title=User:Example_4&action=edit&redlink=1" class="new" title="User:Example 4 (page does not exist)">User:Example 4</a></dd>
</dl>
</dd>
</dl>

It's easy to check that sticking with the same bullet at the start of each line produces one main list with the others inside it, which is much cleaner. HTH --RexxS (talk) 15:26, 13 August 2016 (UTC)

As a general rule, lists of the three main types may be nested, but when one type is nested inside another, the thing to do is to copy the list markup from the post above, and add a list markup character to the right-hand end of whatever you copied. So, a definition list inside an unordered list would be

*First item of unordered list
*:Definition list nested inside first list item
*::Definition list nested inside definition list
*Second item of unordered list

This preserves the coherent list structure. Compare an improper method that I sometimes see

*First unordered list
:*Unordered list inside definition list
::*Unordered list inside definition list nested inside definition list
*Second unordered list

This gives three distinct outer lists, there is nothing to relate one to the next. --Redrose64 (talk) 19:30, 13 August 2016 (UTC)

"What we should have is probably..." - Why not just:

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

-- ? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 13 August 2016 (UTC)

It's also fine. You see the difference when you have multiple comments and replies. It's the difference between:

• Support. I like this idea. User:Example:

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

  Reply: It rocks. User:Example

• Oppose. I hate this idea. User:Example3:

  Question: What do you hate about it? User:Example 4

  Reply: It sucks. User:Example3

and:

• Support. I like this idea. User:Example:
  • Question: What do you like about it? User:Example 2
    • Reply: It rocks. User:Example
• Oppose. I hate this idea. User:Example3:
  • Question: What do you hate about it? User:Example 4
    • Reply: It sucks. User:Example3

In the latter style it's difficult to actually include a genuine bulleted list when needed. Some may also find that the former style helps show the start of each primary comment, especially when the thread is long. --RexxS (talk) 21:43, 13 August 2016 (UTC)

So is there no way of creating a list like this without indenting the information? - adamstom97 (talk) 23:15, 13 August 2016 (UTC)

A list like what? There are several examples of lists above, which have you in mind? --Redrose64 (talk) 09:13, 14 August 2016 (UTC)

This example from above,

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

is pretty common across a lot of articles. If it is an issue, is there an alternative that doesn't indent the second part? - adamstom97 (talk) 09:29, 14 August 2016 (UTC)

Example 2 is replying to Example so it should be indented, per WP:THREAD. So the correct form would be

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

This places a <dl>...</dl> inside the first <li>...</li> of the existing <ul>...</ul>, which remains open for its second <li>...</li> (not shown above). --Redrose64 (talk) 10:15, 14 August 2016 (UTC)

I guess that wasn't the best example to use then. I am talking about instances of actual lists, such as the Supergirl example raised above. Those sorts of character lists are always formatted with a single bullet for the actor and character name, followed by a single colon for the extra information. Now, this has been changed to what it currently is, with the extra information indented. Is there no other alternative, without an indent? - adamstom97 (talk) 12:39, 14 August 2016 (UTC)

Semantically, it should be a list of definition lists, but you won't like the way your browser formats that. Anyway, you mean you want it to look like this?

• Melissa Benoist as Kara Zor-El / Kara Danvers / Supergirl:
  A 24-year-old Kryptonian living in National City, who must embrace her powers after previously hiding them. She assists her adoptive sister as part of the Department of Extra-Normal Operations (DEO) as she discovered the truth that her foster father also worked for the DEO so they would not take her, while Alex's co-workers at the DEO help her perfect her powers. Kara works as Cat Grant's assistant at CatCo. Benoist expressed her excitement over portraying the character, and being able to "[tell] a story about a human being really realizing their potential and their strength". Malina Weissman portrays a young Kara.
• Chyler Leigh as Alex Danvers:
  Kara's adoptive sister. She is a doctor and scientist who works for Hank Henshaw at the DEO. Having been extensively trained in combat after joining the DEO, Alex in turn provided rigorous training to Kara in order to decrease her reliance on her powers. Initially, like Kara, she becomes suspicious of the DEO and thus her own role upon learning of their father having worked there in order to protect Kara, but Alex ultimately learns that Henshaw is the Martian survivor J'onn J'onzz in shape-shifted disguise, whom her late father had rescued before his and the real Henshaw's deaths. Jordan Mazarati plays a young Alex.

You can have it looking like that instead if you want. Just use <br> to get a new line. --RexxS (talk) 20:32, 14 August 2016 (UTC)

@Adamstom.97: "a single bullet for the actor and character name, followed by a single colon for the extra information" - that's two lists, with one item each. Not good. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:42, 30 August 2016 (UTC)

Lightweight pages via Google

I thought that this might interest some of you. Last year, Google started transcoding websites, including Wikipedia, to reduce page weight (and therefore the cost of reading and page loading time) for people using mobile devices with slow connections. There's some information on their blog. You can compare the results here:

• https://en.m.wikipedia.org/wiki/Oxygen
• https://icl.googleusercontent.com/?lite_url=http://en.m.wikipedia.org/wiki/Oxygen

It seems to remove Javascript as well as all images. (Also @Guy Macon:, who has been interested in issues of page weight in the past). (Please ping me if you need my attention; I'm not watching this page.) Whatamidoing (WMF) (talk) 08:36, 30 August 2016 (UTC)

Related:

* http://searchengineland.com/google-launches-streamlined-lite-version-of-mobile-search-interface-for-slower-connections-218269

* http://searchengineland.com/google-testing-faster-lightweight-mobile-search-optimizing-your-web-page-for-slow-connections-220031

One thing that some might find interesting is that the version that Google is testing in Indonesia does not send Google search engine users to Wikipedia, but to the Google-optimized version of the Wikipedia page with all links modified to bring up Google-optimized versions of the linked Wikipedia pages. This allows Google to log which Wikipedia pages the user reads, something that they cannot do when a user accesses the real Wikipedia. It also makes it so that we don't know how many views a page gets.

It seem to me that we can do the same thing Google is doing, and maybe even do it better`(our code would only have to work on Wikipedia, their code must handle all sorts of oddball HTML markup on random sites). @Whatamidoing (WMF): --Guy Macon (talk) 12:30, 30 August 2016 (UTC)

I understand that it's more than Indonesia. They started doing this in India a couple of months after Indonesia, and had several more countries planned.

I seem to recall you saying that you were going to collect some data on page weight a while ago. Did you make any progress on that? Whatamidoing (WMF) (talk) 22:31, 30 August 2016 (UTC)

For a while I was trying as hard as I can to get anybody at WMF to discuss the simple change of replacing the CR+LF in our HTML output with LF. I chose that as being simple to do, easy to understand, 100% guaranteed to reduce page weight, and 100% guaranteed to not affect anything else.

The closest I got was one person (not someone who has the authority to actually make the change) who opined that there is no difference if you use page compression and challenged me to prove him wrong. To respond to that I would have to set up a server just like Wikipedia, test it with a bunch of browsers, and try to get some statistics as to what percentage of browsers in my target audience (people in the third world using very slow satphone or modem connections) has the ability to accept a compressed page. And even if I demonstrated that there is a difference even with compression, I still would be no closer to having a meaningful technical conversation with someone who has the ability to make the change.

So, having utterly failed at avoiding being stonewalled on this simple test case, I gave up in defeat. The WMF doesn't want my input, and if they say they do they are lying. --Guy Macon (talk) 07:00, 31 August 2016 (UTC)

Looks like the "reader" view in Firefox. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:34, 30 August 2016 (UTC)

Right what it does seems to be the following:

1. remove almost all whitespace from the document
2. remove all images, comments, stylesheets and javascript
3. remove all content elements that are hidden by the original CSS.
4. remove all meta/head elements, from noindex to favicon, creative commons licensing and the canonical url indicator
5. remove many element attributes, including those indicating language, directionality etc.
6. replace all skinning with a very lightweight skin
7. use javascript to load 'below the fold'-content after the initial page load. This together with images actually is responsible for the majority (80% I estimate) of the reached speedup. (also totally breaks if you don't have Javascript)
8. of note is also that this extra processing adds about 2-3 seconds to the initial response time. So your overall time to 'first paint' would have to be over at least 3 seconds slower before this starts making sense.

While some of these things would be doable for Wikipedia, many also would be totally impossible / not acceptable to the community or hugely cost prohibitive. Mobile is currently adding lazy loading of images and that is already quite a challenge, and while whitespace removal seems simple, I'm pretty sure it's not as simple to implement, if you also want to keep the 'readable' versions of your pages available. Lastly part of why this works so well for Google has to do with the fact that they can detect your speed before you arrive at wikipedia. They use that 'extra time' that the user is spending at google, to decide where to direct the user to, giving both groups different experiences without bothering each other. We don't have the benefit of this measuring moment, making it much more difficult to make that split in user groups and not bother the groups, and even with that nice split, that would multiply our caches and complexity of our infrastructure once more (cost). —TheDJ (talk • contribs) 12:06, 31 August 2016 (UTC)

I am a big believer in letting the user choose with a link or checkbox rather than trying to be smart and guessing which version of the page they need. --Guy Macon (talk) 15:54, 31 August 2016 (UTC)

RfC on quotation templates

FYI

 – Pointer to relevant discussion elsewhere.

Please see "Wikipedia talk:Manual of Style#RfC: What (if anything) to do about quotations, and the quotation templates?". Some specific accessibility issues have been raised about particular templates, and there's a test of a mild background shading to the default {{Quote}} template. Please examine the entire RfC; someone later opened a "voting" section about one particular template, but it does not address the majority of the questions and concerns raised in the RfC.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:46, 11 September 2016 (UTC)

Updated "Scrolling lists and collapsible content" section at main MOS

FYI

 – Pointer to relevant discussion elsewhere.

I've updated WP:MOS#Scrolling lists and collapsible content, the first major re-examination it has had in a long time (and much has changed, like the Google transcoding in Asian countries mentioned above at WT:ACCESS). Overview at WT:MOS#Updated "Scrolling lists and collapsible content" section, and diff here]. It's possible this updating may need to be reflected in MOS:ACCESS. It might even be desirable to move some of that into MOS:ACCESS and make the segment at the main MOS page shorter, though most of the additional material is footnotes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:32, 11 September 2016 (UTC)

Template:Based on

I have updated {{Based on}} to use a Lua module which automatically uses {{Unbulleted list}} for multiple writers rather than semantically incorrect line breaks which were previously recommended by the template documentation. Someone might want to run over existing transclusions with a bot and replace <br /> (and variations) with |, i.e. use separate parameters for multiple writers. nyuszika7h (talk) 14:06, 13 October 2016 (UTC)

Screen readers

There is a discussion at WikiProject_Albums regarding headings. The advice is not to use basic mark up for MOS:DEFLIST type situations because "Screen readers and other machines can only use correctly formatted headings for navigation." A while ago I downloaded a screen reader to see what the issue was, the reader treated "==" and ";" formatted headings the same. I tried another one again today (http://www.nvaccess.org/download/) and that is also fine. Is it the case that when the screen reader details were added (back in 2012 I think) that such readers couldn't deal with the ";" formatting, but they can now? Would it appropriate for a bunch of us to try out various screen readers to see what issues are created when using them while reading Wikipedia? SilkTork ^{✔Tea time} 13:29, 13 November 2016 (UTC)

Screen readers haven't changed at all in this respect. For instance, in NVDA, the heading navigation keystrokes (h/shift-h) only work for fully marked-up headings, as they're designed to. Graham87 14:07, 13 November 2016 (UTC)

Add to that, using ";" creates a definition list (now called an "association list"), not a heading. Just because something looks like a heading (for example, bold) to a sighted person doesn't mean that someone using assistive technology will perceive it as bold or as a heading. Bold is not the same as a heading; and a definition list is used to mark up a term and then its definition, as in a glossary. It's really not kind to the visually impaired to force them to figure out what when they hear "definition list", we intended them to hear "heading". --RexxS (talk) 19:12, 13 November 2016 (UTC)

Ah. I think I was misunderstanding. When the def list markup is used, it is not intended to be a formal heading - in the discussion linked, the section heading is Personnel, and what goes in that section is a list, which may be sorted into associated groups such as Session musicians, Producers, etc. These sub-lists are not appropriate for formal headings, particularly as they sometimes may consist of only one or two members. What should we do in cases where we want to use a description or association sub-list, but don't want to confuse users with screen readers? As I can see the text, and know the context, it is clear to me that it is intended to introduce a list which relates to the group name. There would not be an intention in most cases for anyone to jump to a specific list in the section from the table of contents. If there was a particular notable value in such a sublist, then a separate section or sub-section with appropriate level headings would be created. But it would likely weigh down a TOC to have fairly mundane details, such as a list of everyday session musicians, included. What I am saying is that because I can see and know the intention I am not seeing the likely confusion when using a screen reader because it appears to me that a non-sighted reader would understand the context when the sight reader says: "Sessions musicians Arnold Belnick – violin Chuck Berghofer – string bass". The linked discussion uses the Personnel list in Pet Sounds as an example; so is there a problem using this style with def list formatting, instead of this style with sub-headings? SilkTork ^{✔Tea time} 01:00, 14 November 2016 (UTC)

In WP:PSEUDOHEAD, there is the suggestion to use {{TOC limit}} to keep the table of contents from overflowing if you're using lots of sub-headers. — Gorthian (talk) 01:15, 14 November 2016 (UTC)

@SilkTork: Using "====" Wikimarkup to produce subheadings is always going to be the most compatible choice for fragments that are undoubtedly subheadings like "The Beach Boys" in the "Personnel" section, or "Albums" in the "Charts" section. You really have to ask yourself why you wouldn't want to mark them up as sub-headings? In some rare cases you won't want to use {{TOC limit}} because you want to display some level 3 headings but not the ones in the Personnel or Charts sections.

Nevertheless, if you think a section of text makes sense as a definition/association list, then you can use ';' markup for the "definition" term (like The Beach Boys), but then you have to complete the list by marking up the definitions with ':'. There's no escaping that: the two pieces of wikimarkup together produce the definition/association list - the first one on its own is just a recipe for confusion. As an example, if you use ;The Beach Boys followed by * Al Jardine ..., the html introduces a definition list, <dl>; then gives a definition, <dt>The Beach Boys</dt>; but then closes the definition list <dl> without ever defining anything! It then begins a separate bulleted list <ul><li>Al Jardine ...</li>, etc.

In other words, you can choose either (1) ===The Beach Boys=== followed by * Al Jardine ... (i.e. a heading followed by a bulleted list); or (2) ;The Beach Boys followed immediately by : Al Jardine ... (which makes a complete definition list). But half of one and half of the other makes no sense at all.

That's what WP:PSEUDOHEAD is summarising. It does add that if you can't or won't use toclimit, then marking the subheadings in bold gives sighted readers a cue that these may be subheadings without causing the problem of incomplete definition lists for the screen readers. Of course it doesn't give them the advantage of being able to jump directly to the section, either, but that's going to happen as soon as you make the decision not to use heading markup anyway. Hopefully that clarifies a little the advice given about pseudo-headings. --RexxS (talk) 02:38, 14 November 2016 (UTC)

But these lists are not meant to be in sections. Think of them like sentences: "The session musicians were Arnold Belnick on violin, Chuck Berghofer on string bass" but converted to a list to make reading easier, as described in WP:Def list, which says they are more accessible for screen readers. In the sentence "Do not make pseudo-headings using semicolon markup" I think there is a misunderstanding regarding what is meant by pseudo-headings. We don't advocate using pseudo-headings on Wikipedia. The sentence is being interpreted as meaning "do not use semicolon markup as this is unable to be read by screen readers". But I don't think the guide here is saying "don't use def list mark up", it is saying "don't do something [create "pseudo-headings"] that we don't do on Wikipedia anyway". I don't think we need a special accessibility instruction for something we don't advocate doing anyway. But we do need compatibility between guidelines, and some clarity on when and how to use def lists appropriately to help all readers. Personally I prefer prose, but I understand that most readers prefer some details to be presented in lists, and I can handle that. But we shouldn't be forcing association lists into section headings because that's going a stage too far, and making reading more awkward for all. SilkTork ^{✔Tea time} 09:43, 14 November 2016 (UTC)

The lists in Pet Sounds are clearly in sections (or sub-sections to be accurate) and if you're going to give them a (sub)heading, you ought to use a (sub)header. WP:Def list says "Properly formatted definition lists are more accessible to people using screen readers ...". That's properly formatted definition lists, not a ';' on its own or mixed in with unordered lists. Are you able to read html? If you are, inspect the the following three examples:

Production

• Bruce Botnick – engineer
• Chuck Britz – engineer
• H. Bowen David – engineer
• Larry Levine – engineer

Production

Bruce Botnick – engineer

Chuck Britz – engineer

H. Bowen David – engineer

Larry Levine – engineer

Production

• Bruce Botnick – engineer
• Chuck Britz – engineer
• H. Bowen David – engineer
• Larry Levine – engineer

Can you see that the first example has a section heading and one unordered list of four items? That the second example has one list (an association list) with an association term and four 'associations'? And that the third example has two separate lists: the first being an association list comprising an association term but no associations; and the second being an unordered list of four items?

Why would we want to tell someone using assistive technology that there are two lists in each section?

An association list <dl>...</dl> is the only list in html that has its own in-built header <dt>...</dt> to go with the list items <dd>...</dd>. And we are sometimes misuse that <dt>...</dt> to try to create headings for other sorts of lists (pseudo-headers), which are visually acceptable but which are never going to be read properly by screen readers because the underlying html is bolixed. That's why we have the advice not to use ';' for pseudo-headings. --RexxS (talk) 12:06, 14 November 2016 (UTC)

I just would like to know what I should be using instead. Please ping me for the conclusive answer. --Jennica✿^{Ping Me!} 00:33, 17 November 2016 (UTC)

I'm not clear on what is intended to be meant by pseudo-headers. Does it mean "appropriate headings created using inappropriate mark-up", or "inappropriate headings created using inappropriate markup" or "inappropriate headings created using appropriate markup"? As this is an accessibility guideline I am assuming it means "appropriate headings created using inappropriate mark-up", in which case perhaps we should simply say that to avoid confusion. That would be a start. That we could guide people toward how they should be presenting the headings. SilkTork ^{✔Tea time} 11:15, 17 November 2016 (UTC)

I have just gone though the examples above and see what you mean. I wasn't using the screen reader properly previously. Just now I allowed it to read by itself rather than me pointing at the words. In sample 2 it says something like "Title Production, list of five items, link Bruce Botnick engineer..." (it appears to treat the title as an item in the list) while in the third example it says something like "Title Production, list of one, list of four items, link Bruce Botnick engineer..." (creating two separate lists). Neither using ":" nor using "*" gives a satisfactory reading of what is on the page. However, when using this

Production

• Bruce Botnick – engineer
• Chuck Britz – engineer
• H. Bowen David – engineer
• Larry Levine – engineer

or this

Production:

• Bruce Botnick – engineer
• Chuck Britz – engineer
• H. Bowen David – engineer
• Larry Levine – engineer

It reads it as "Production list of four items link Bruce Botnick engineer..." which seems to me to be fine as the meaning will be understood. I don't see why we need to have in bold, as that doesn't necessarily assist meaning for a sighted reader. Personally I would prefer a prose sentence: "The production engineers were Bruce Botnick, Chuck Britz, H. Bowen David, and Larry Levine." But people like lists. We could have:

The production engineers were:

• Bruce Botnick
• Chuck Britz
• H. Bowen David
• Larry Levine

Guest musicians were:

• Tony Asher – plucked piano strings on "You Still Believe in Me"
• Terry Melcher – tambourine on "That's Not Me" (uncertain) and "Here Today"

Sessions musicians were:

• Arnold Belnick – violin
• Chuck Berghofer – string bass
• Hal Blaine – bongos, drums, timpani

Would that be acceptable? SilkTork ^{✔Tea time} 12:22, 17 November 2016 (UTC)

That would be fine by me. Graham87 14:40, 17 November 2016 (UTC)

That's exactly right, SilkTork, I'm sorry I wasn't clearer in the first place.

As for "pseudo-headings", I've always taken it to mean an html element that performs the function of a heading in its context, but isn't marked up as a heading (i.e. with <h3>...</h3>, etc.). It can result in something that looks like a heading to a sighted reader, but which has no semantic markup available for assistive technology or for other automated tools. --RexxS (talk) 18:54, 17 November 2016 (UTC)

@Jennica: Any of the following would be fine:

==== Production ====
* [[Bruce Botnick]] – engineer
* [[Chuck Britz]] – engineer
* [[H. Bowen David]] – engineer
* [[Larry Levine]] – engineer

'''Production'''
* [[Bruce Botnick]] – engineer
* [[Chuck Britz]] – engineer
* [[H. Bowen David]] – engineer
* [[Larry Levine]] – engineer

;Production
: [[Bruce Botnick]] – engineer
: [[Chuck Britz]] – engineer
: [[H. Bowen David]] – engineer
: [[Larry Levine]] – engineer

The first is best; the second is acceptable; the third is possible, but doesn't match most readers' expectations of how lists should look. In any case, mixing ';' with '*' is problematical. Is that definitive enough? --RexxS (talk) 18:54, 17 November 2016 (UTC)

RexxS (talk · contribs) yes it is. Thank you. I've actually come across a new one and was wondering what it comes up as on a screen reader Weezer_(2008_album)#Personnel - with big headers. --Jennica✿ ^{talk / contribs} 05:32, 20 November 2016 (UTC)

These are pseudoheadings, and the <big>...</big> tags are obsolete in HTML5. They're not exactly against our MOS:FONTSIZE, although better ways exist. On another matter, the section in question has {{col-start}} {{col-break}} and {{col-end}} - but these are rather pointless when there is only one column. --Redrose64 (talk) 10:31, 20 November 2016 (UTC)

Presenting redirects on mobile devices

I identified an opportunity to improve the way that redirect information is presented at Template_talk:Redirect#Targeting_the_message. It was suggested that I mention the idea here in case it spurred interest from anyone is in the accessibility crowd. If so, feel free to pick up the discussion there, or here if more appropriate. --Ed Brey (talk) 17:26, 21 November 2016 (UTC)

Template:Legend and WP:ACCESS

I'm wondering wether {{Legend}} is even compatible with WP:ACCESS. It's a template that allows the creation of color-based only legends with no other means to provide the same information. This seems to be in direct contradiction to the spirit of this guideline for obvious and logical reasons. So I question whether this template should be recommended, let alone used. Any thoughts?Tvx1 20:51, 22 November 2016 (UTC)

The template can be useful inside an image definition to simplify the provision of a caption, as show in Template:Legend #Use in a caption. For images that convey information only by colour, such as shaded maps, sighted visitors need a legend. Meeting WCAG SC 1.4.1 requires us to provide text in the body of the article to convey the information that the image+legend provides to a sighted reader, regardless of how the legend is constructed.

I would worry about editors using the template outside of image captions, however. The use of coloured rows or cells in tables without corresponding text to convey the information is a problem for accessibility, and I wouldn't want this template to encourage that practice. Nevertheless it's the misuse of colour in the table that is the culprit; this template would be merely an accomplice.

Perhaps you could suggest (or make) improvements to the Template:Legend documentation to clarify acceptable uses of the template? --RexxS (talk) 22:44, 22 November 2016 (UTC)

{{color sample}} and accessibility

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

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

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

Listgap: a proposal

@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 (‍Y‍) 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

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}}

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

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. [14][15]"

— Preceding unsigned comment added by Pigsonthewing (talk • contribs) 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

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 (talk • contribs) 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)