Wikipedia talk:WikiProject Accessibility/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 8

American football box

I'm concerned about the table structure in {{Americanfootballbox}}. Can someone give me a sanity-check on that, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:49, 6 February 2012 (UTC)

XHTML-wise, I think that it's got unbalanced </th> and </td> in the R5/H5 column. --Redrose64 (talk) 21:10, 6 February 2012 (UTC)

Infoboxes about persons

I would like to inform your Wikiproject that I added |alt= support to all infoboxes about persons who were lacking it. Example. This will help add alt descriptions to images. -- Magioladitis (talk) 21:25, 23 February 2012 (UTC)

Disabling of preference for wikieditor

A patch has been merged into mediawiki which removes the preference for enabling/disabling the WikiEditor and enables it for all by default. A discussion regarding this is ongoing at Wikipedia:Village_pump_(technical)#Disabling_of_preference_for_wikieditor. All users are requested to comment.--Siddhartha Ghai (talk) 08:22, 7 April 2012 (UTC)

Screen magnification software

I was wondering if we have any guidelines for helping editors who use screen magnification software, and if we don't whether it would be worth writing an essay on the subject. On a personal level I sometimes find aspects of the GA and FAC process to be difficult because it can require one to address problems relating to graphica, images, etc, which I find to be a challenge. People can also sometimes be very general as to where issues arise within an article, which in itself can present problems. I recently nominated an article for FAC where some of these things arose, and got a lot of help when I explained my situation. I think it would be useful if we had a page that people could refer to, explaining both what the software does, some of the challenges it can present to those who use it, and how other Wikipedians could help. If there's consensus to do it, I'll write something based on the Screen magnifier article and add some of my own ideas. Any thoughts guys? Paul MacDermott (talk) 11:36, 17 April 2012 (UTC)

Signature colour argument

There is an argument about the use of colours in editors' signatures. Pleas comment here. Axl ¤ [Talk] 22:02, 27 May 2012 (UTC)

This issue is interesting and worth discussing. But I fear that in the current context we might not be able to find a satisfying solution. Users are able to fully customize their own signatures, to a point which cannot ensure quality and accessibility. It's their own signatures - like a private property - so we can't change it for them. Several users a going to (blindly) oppose a policy proposal for signatures. Sorry about that. Yours, Dodoïste (talk) 21:33, 29 May 2012 (UTC)

Black text in tables

I am using green-on-black text to reduce background brightness. "M27 motorway" has a table with "km" and "Junction" columns, which I can't read, presumably because they use black text. Other motorway articles don't have this problem.

After the argument that ensued following my previous comments about editors' signatures, I am reluctant to change anything myself. Axl ¤ [Talk] 16:40, 29 May 2012 (UTC)

Hi. I tried to understand the difference between this table compared with others, and your specific contrast. I don't understand the problem. Could you provide a screenshot of the table you see at M27 compared to a normal motorway table ? It would allow me understand where the problem come from, and fix it. Yours, Dodoïste (talk) 21:14, 29 May 2012 (UTC)

If you switch the green on black display the M2 junctions table text [1] renders green. The M27 data is invisible. The structure of the tables appear to use different syntax. Leaky Caldron 21:32, 29 May 2012 (UTC)

Ah, I see now. It's my first time to turn on this contrast tool (which is doing a pretty good job by the way, useful).

Okay, so after some testing I found the issue. Going to save a fixed version soon. Dodoïste (talk) 21:41, 29 May 2012 (UTC)

Fixed. The problem was indeed that the text was forced to black needlessly, and caused the problem to Axl. It was done in a way I did not expect, so I did not saw it at first. :p Cheers, Dodoïste (talk) 21:50, 29 May 2012 (UTC)

Well done! Leaky Caldron 21:51, 29 May 2012 (UTC)

Thank you. Axl ¤ [Talk] 08:08, 30 May 2012 (UTC)

Aviation accidents and incidents template

I've just raised an issue with the accessibility of {{Aviation accidents and incidents}} - Please comment on its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:08, 4 June 2012 (UTC)

Media wiki software for bold and italics

I recently discovered that our markup for bold and Italics uses <b> and <i> rather than <strong> and <em>. Would wikipedia be more accessible if the strong and emphasis tags were the default instead? What other options exist? I did recently discover (as I typed this post) {{em}} and {{strong}} which cause semantic change; however, having been unaware of those templates for the first year and a half that I've been on the site, and I doubt that many editors use them. Ryan Vesey Review me! 17:45, 15 June 2012 (UTC)

This has been proposed previously and rejected (bugzilla:1038). The issue is that the use of ''' and '' in wikimarkup does not always correspond to the semantic meaning inherent in <strong> and <em>. Italics especially are sometimes used for emphasis, but much more often for things like the titles of works. the wub "?!" 21:05, 16 June 2012 (UTC)

Would it be conceivable for the software to treat it differently in the article space and in any other Wikipedia space? I know there are editors who use screen readers and bold and italics are used almost solely for their semantic meaning on talk pages and Wikipedia space. In addition, if I come across italics used for emphasis in an article, it would be correct for me to change from '' to em (using {{em}} to avoid html), correct? Ryan Vesey Review me! 06:21, 17 June 2012 (UTC)

It's a non-issue for screen reader users; it doesn't make any difference. Graham87 06:31, 17 June 2012 (UTC)

Hey Graham, please don't say that! ;-) Your screen reader JAWS can differentiate <b> and <i> from <strong> and <em>, and read them accordingly. There is an option in the JAWS menu to enable emphasis. I've heard many screen reader users don't use this feature. Some are probably not aware of this option, and some might dislike it?

In any case, emphasis can be used by screen reader users who wishes to do so. There is no data available about the use of this preference though, so I can't tell if it is widely used or not. Dodoïste (talk) 21:34, 18 June 2012 (UTC)

Indeed! I stand corrected. I personally don't like it, but I can imagine that some people would, and it'd be useful in certain situations. Graham87 00:48, 22 June 2012 (UTC)

Maybe we could just encourage editors to use {{em}} and {{strong}}? Ryan Vesey Review me! 02:24, 22 June 2012 (UTC)

On a scale from 1 to 10, I'd rate this issue a -10, TBH. Graham87 16:24, 22 June 2012 (UTC)

Well, semantic emphasis "em" and "strong" are a AAA accessibility requirement after all. AAA means that it is an optional requirement, but might benefit to some users (not all). It distinguishes from A and AA accessibility requirements which are mandatory. Dodoïste (talk) 13:19, 6 July 2012 (UTC)

Changes in thumbnail alt text

A patch has been submitted based on a review of accessibility that might benefit from your input. Please see https://bugzilla.wikimedia.org/show_bug.cgi?id=34750. —TheDJ (talk • contribs) 07:55, 3 July 2012 (UTC)

Thanks for the notification. This is an important issue, and we've been aware of it for a long time. It's good to see that it has gained attention from developers, thanks to the Wikimedia German chapter.

It seems that it is going in the right direction at a first glance. However I would like to request a few days, in order to discuss this change with volunteers here (User:RexxS) and experts from the french Wikipedia. We've also discussed it already at the french Wikipedia, I'll try to find the corresponding archives...

In short: thanks again, and I'm working on gathering input. Dodoïste (talk) 18:28, 3 July 2012 (UTC)

TheDJ, I'm not familiar with PHP and I have trouble understanding the diff. And thus the specifics of the changes. Could you translate for me?

1) In this diff 1 I see the following changes.

• There was a duplicate of links a to the media page, it is now reduced to one link. Good. But has it been done in every instance, as I see some that still have the redundant link?
• Some useless DIVs were replaced by SPANs. Good.
• The confusing title "enlarge" is replaced by the clearer "View the media page". I'll see with experts if it can still be improved. Sounds good.

2) I don't understand this second diff. Newbie help please?

3) Same here with this third diff.

Now there was some discussion about getting the name file into the alt text if none was provided. In the case of File:ECARmulticolor4.tnl.jpg it would be read aloud "ECARmulticolorfourdottnldotjpg". Hopeless case. Now the file titles should be descriptive, but in practice a great many are not. Thus this is not reliable, and might worsen the situation.

Did I miss any other change? Cheers, Dodoïste (talk) 23:31, 3 July 2012 (UTC)

Looks good to me. The principal improvement is ensuring that linked images always have some alt text so that the screen reader gets some info about where the link would go. That's goodness, and so is the reduction in the number of duplicated links.

If I can help, the second diff noted above makes sure that if there is no alt text supplied, it is set to a message like "View media page". If there is additionally no caption then the filename is appended to that, so it sounds something like "View media page colon ECARmulticolorfour dot tnl dot jpg". Yuk! Personally, I wouldn't have bothered as the alt text would be spoken well before the caption: the screen reader user would have already had to make a decision on whether to follow the link or not before they discovered that no caption existed. Frankly, until we do a better job of writing informative image filenames (never), I'd encourage developers to give up on using filenames anywhere in alt text.

The third diff sorts out the zoom icon and gives it the same title as the image at the same time as silencing its alt attribute. That certainly seems like an improvement to me. --RexxS (talk) 00:37, 4 July 2012 (UTC)

Thanks for your comments and explanations, RexxS. :-)

I've commented too at bugzilla. I hope the issue with the default alt text I raised at bugzilla will be fixed. I was not able to get advice from the french experts. I guess this is it all we can do for now. Cheers, Dodoïste (talk) 13:16, 6 July 2012 (UTC)

Small caps templates

Unresolved

A TfD I started on Template:Smallcaps all has been closed as "no consensus to merge, but consensus to fix improper transclusions, and to make improvements to make the template closer to complying with accessibility guidelines". At Template talk:Smallcaps all#Changes needed from results of TfD, there's now a discussion to fix those accessibility problems. I've added my opinion (which is that the template is wholesale incompatible with those guidelines), but editors interested in accessibility may wish to add theirs there, along with any suggestions, too. — OwenBlacker (Talk) 22:51, 27 March 2012 (UTC)

Discussion petered out; and could do with extra input. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:08, 30 July 2012 (UTC)

Colored fonts

Hi. If I read Wikipedia:Font#In_prose correctly, for accessibility reasons all the colored prose fonts in Line 2 Orange (Montreal Metro) and other Montreal Metro line articles have to go, is that right? Shawn in Montreal (talk) 15:48, 26 July 2012 (UTC)

Yep. The table background is   whereas the text is   which looks like this - the contrast ratio is just 1.88:1 which fails WCAG 2.0 --Redrose64 (talk) 16:07, 26 July 2012 (UTC)

Thank you. This is all quite new to me. Shawn in Montreal (talk) 18:18, 26 July 2012 (UTC)

I'm not sure how to remove all this elaborate coloring without damaging the table, and there isn't a monochrome version with the same dimensions that I can copy and paste from a previous version of the article. Is there anyone on this Wikiproject who wishes to remove the colors? Just thought I'd ask. Shawn in Montreal (talk) 18:34, 26 July 2012 (UTC)

Wait, I see stalwart User:MTLskyline has come to the rescue here on the Green line's table. I'll ask him. Shawn in Montreal (talk) 18:40, 26 July 2012 (UTC)

Considering Line 2 Orange (Montreal Metro) - this article draws the table using raw HTML (HTML 3.2 for the purists) - the <table>...</table>, <tr>...</tr>, <th>...</th> and <td>...</td> elements. It uses a mixture of HTML attributes on the table rows (to set the background colours) and the <font>...</font> element (to set the text colour). In this case, you would proceed as follows:

1. Fix the background of the header row by removing bgcolor={{Montreal Metro color|Orange}} (i.e. change <tr bgcolor={{Montreal Metro color|Orange}}> into <tr>)
2. Fix the text colour of the header row by removing <font color=white> and </font> (but leave the text between those alone)
3. Similarly, fix the text colour to the individual rows by removing <font color=blue> <font color=green> <font color=orange> and all the </font>

--Redrose64 (talk) 20:16, 26 July 2012 (UTC)

Hey, I'm thinking it might be best just to convert the whole thing to a wikitable format, as I did with the tables in the articles about the Green line and Yellow line. It might take a little longer to fix it, but it will also be easier to edit aftewards, IMO. I have been meaning to get the the Orange line's as well, but completely forgot about it. I'll try and remake the Blue line's as well.--MTLskyline (talk) 22:22, 26 July 2012 (UTC)

I made a wikitable version in my sandbox. If someone could take a look over it just to make sure everything is correct, and then I'll transfer it over.--MTLskyline (talk) 23:22, 26 July 2012 (UTC)

Oh, science and MTLskyline be praised: I was hoping you'd come along. It looks fine to me, after comparing the two. I mean, you've eliminated the group field (right word?) for stations that have been opened the same day, but I can't imagine our railfan editors are going to care about that -- and if they do, they can change it. Shawn in Montreal (talk) 23:30, 26 July 2012 (UTC)

Great, I just transferred it over. I'm not exactly sure how to do a group field in a wikitable though. I will try and work on the Blue line's as well.--MTLskyline (talk) 00:31, 27 July 2012 (UTC)

I'm not sure what you mean by a "group field", but assuming that you mean a cell that spans multiple rows or columns, you would use the rowspan=n or colspan=n attribute just as with the <td>...</td> construct. I've not amended the live copy, just in case this isn't what you mean, so instead I've amended your sandbox so that one of the cells in the second column spans three rows as an example. --Redrose64 (talk) 08:47, 27 July 2012 (UTC)

Yeah, that's what I meant. Thanks!--MTLskyline (talk) 20:56, 27 July 2012 (UTC)

Thanks Redrose64 and MTLskyline, you did a very good job; it's a great accessibility improvement. Cheers, Dodoïste (talk) 06:52, 28 July 2012 (UTC)

Wikiquote

Those of you who use Wikiquote may be interested in Wikiquote:Village pump#Accessibility and the new, draft Wikiquote:Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 31 July 2012 (UTC)

Improving Wikiquote is a good idea. But I'm not sure it's a top priority right now, and doing things well require lots of time. Before jumping in though, let's discuss the key points. Improving quotations semantics seems like the most important change, since Wikiquote contains mostly quotations. Currently formatted as a list, which is not appropriate but not a blocking issue either. We could use blockquote, but users don't seem to like its resulting layout. We might be able to adjust the layout to some extend, but which extend? Providing an accessible layout that they would prefer of the inaccessible one is the key here.

The Q (quote) element is currently unavailable, it's not allowed by MediaWiki. Some developers did not want to add more complex syntax without a strong motive, which is understandable even if we do need it. The absence of the Q element is the reason why I haven't written guidelines about quotes yet. For now, users should use citation templates, in order to enable us to easily add Q when implemented. Wikipedia users are already using templates, why bothering them? Wikiquote users should use template for quotations, so that we could fix this issue later on easily. They might not like this proposal : it's going to make the wikisyntax more complex and unfriendly.

There's also a few images at Wikiquote. They are portraits: they carry little information. Users are writing good captions, at that. The solution is trough bugzilla:34750.

In conclusion, I don't see any simple improvement to do right now. But some research could be done on adapting the blockquote layout. Your enthusiasm is welcome, though, and we need fresh ideas. If you want to improve Wikiquote, you have my support. My advice would be to show patience, and to use a "small steps" approach. Cheers, Dodoïste (talk) 21:38, 31 July 2012 (UTC)

Discussion of Wikiquote belongs on that project, not here; I merely posted here to notify interested parties. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

Well, yeah. But I feared my explanation would not make any sense for them. Dodoïste (talk) 00:10, 1 August 2012 (UTC)

Dodoïste, as a regular Wikiquote user I would be very interested if you would like to explain, at Wikiquote, why you think a list format is not appropriate for a compendium of quotations. I don't quite see why, in that context, it impairs accessibility. ~ Ningauble (talk) 16:58, 1 August 2012 (UTC)

Sure, I did not intent to drop the case, just thinking things over and making preparations. I'll reply there. Dodoïste (talk) 17:11, 1 August 2012 (UTC)

Zoomtext problems

Hi Don't know if this belongs here. Iam using the screen magnification and reading program Zoomtext. When i try to read a wikipage the programs get stuck "espcialy on multi column and edit links on wikipages. Some times randomly hoping back and forth in the text or not stating at the top when new screen refreshes have been made by the program. Iam here talking about the application reader mode in the program witch is used for reading webpages. Is this somehow the wikimarkup\css\html that is causing this problem? Does any other user have these problems and is there any good solutions to it? Since wikilanguage isn't standardized it would be better to have wikipedia together with browser vendors propose a standard if wikipedia can't be convinced to abandon this old style of using the web. Sure html isn't perfect but what is and wouldn't a nicer looking page with html5 features be nice to have especialy now that there are good guidlince and standards for accessibility. I love wikipedia but these problems make me have hateful feelings not towards anyone in particular just in general not beeing able to have an acceptable web experience. "there is a trial version for those who want to test my problems." Thanks for any help I can get. — Preceding unsigned comment added by 84.55.88.109 (talk) 14:04, 8 August 2012 (UTC)

If you also have a list of some pages where you encountered problems, that might be useful as well. —TheDJ (talk • contribs) 18:43, 8 August 2012 (UTC)

Number of links on a page

I'm following an interesting discussion on a W3C mailing list, about issues for assistive technology tools, when there are a large number of links on a page.

Comments so far incude:

• Dragon Naturally Speaking also has problems navigating pages with large amounts of links (>200). Some info at http://webaim.org/blog/at-experiment-dragon/
• the mouseless browsing add-on to Firefox also freaks out when there are too many links.

With regard to the former, we have many articles, some featured, with more than 200 links, in the references alone. How can we address this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:00, 9 August 2012 (UTC)

Not, the tools should be fixed. —TheDJ (talk • contribs) 18:59, 9 August 2012 (UTC)

To further explain my opinion on this. Reducing complexity in your content for the sole purpose of making something accessibly has proven to be an exercision in pointlessness. The web is not going to 'restrain' itself just to be more accessible via a specific design of a tool. If this were true, all pages would still work in IE5. Problems like these point at shortsighted (no pun) design by tool builders. So the solution ? Basically, 'smarter' navigation than by tabbing trough links. For instance landmarks, headings, drill down systems (Voiceover is a good example of what i mean with drilldown). A webpage is no longer 1 control as it was 10 years ago. They are full fledged webapps, so to provide accessibility, treat them as applications, and they will be as accessible as every other part of your OS. Not that Wikipedia is that far yet, but we are improving stuff, and the landmark roles for instance are on my personal todo list atm. And if anyone has a good idea to make the linkback from reference to content more accessible (without creating a visual mess), then i'd love to hear thoughts, it has been a challenge that I have not even found a possible solution for so far, let alone implementation. —TheDJ (talk • contribs) 19:10, 9 August 2012 (UTC)

I agree with TheDJ, the tools should be improved. Changing habits and guidelines on Wikipedia, and applying them, takes years. There is only a few patches or updates needed to improve the assistive technologies. Assisstive technologies also have the responsibility to be good enough. Plus, there is no guidelines about the number of links in WCAG 2.0 so we're not supposed to do anything. If something is not in WCAG 2.0 there is probably a good reason for it. WCAG are by no means perfect, but they are well balanced and better than we may think at a first glance. Cheers, Dodoïste (talk) 20:58, 9 August 2012 (UTC)

I agree with everybody above. As an example of assistive technology improvements, JAWS and NVDA now have modes to make it easier to read pages with many links, like Wikipedia; I don't use them because I'm already used to the old way. The guidance on links in the Manual of Style, which has gradually become more strict about linking over the years, is adequate. Graham87 01:03, 10 August 2012 (UTC)

Wikimania presentation about accessibility

I've recently attended Wikimania, the worldwide conference about Wikipedia and other Wikimedia wikis. It was great to meet RexxS from this project who was also at the conference. Of interest to this project, there was a presentation about accessibility in MediaWiki by Eduard Klein, based on an assessment of the German Wikipedia's accessibility.

Many of the recommendations there were to help Wikipedia conform with WCAG 2.0 guidelines. The most interesting one that I remember was to add a field in the upload form for the default alt text for the image. I remember asking about it because previous discussions have determined that alt text is context-specific. I can't remember the exact answer now, but my memory is a bit muddled at the moment as I'm still recovering from jet lag, not at all helped by an eleven-hour delay on one of my flights back to Perth! Graham87 10:29, 29 July 2012 (UTC)

If anything, that should be added to the "insert image wizard" (which we also don't have [deployed]) shouldn't it ? The most important part for me was the whole section on alt, which seems disjoint from our earlier efforts on this front. Personally I'm most interested in getting proper roles added to some of the user interface elements, and the header structure of the main interface in general. However the recommendations also included such problematic suggestions as using -1000px to hide something (headers) from the viewport, which is simply not usable since it breaks rtl interfaces. Similar with accesskeys, that is just not gonna happen. If there are conflicts with browser assignments, then the browsers will just have to be fixed, like Chrome Firefox and Safari have all been able to fix this issue. Again, I find much of the advise to be overly focused on making something accessible (With IE and JAWS), with no regard for the effects (both on other users and on the long term viability of the suggested 'hacks') of the measures applied other than that of accessibility. It is too often tackling the wrong problems and worse, too often dishing out advice that hampers our internationalization or cross browser compatibility efforts. —TheDJ (talk • contribs) 12:24, 29 July 2012 (UTC)

It was a real pleasure to finally meet Graham as well! Indeed, I would agree with both Graham and DJ that the presentation was a little disappointing. The problem of bringing in outside expertise in web accessibility is that they will concentrate on general web standards, WCAG 2.0 in particular. Many of our problems derive not from a lack of technical solutions, but in a failure of many users to deploy them - most obviously a lack of editor awareness that what looks ok to them, may not be accessible on smaller/larger screens, or to folks with degrees of colour blindness, or on low-bandwidth connections, etc. as well as on different browsers and screen readers.

The issue of alt text is symptomatic of the problem. On the one hand, alt text is always context sensitive (mainly because of duplication of caption), so alt text uploaded with the image can't fit every situation. On the other hand, having some relevant alt text is clearly better than none, so including a default alt text in the upload may be helpful some of the time. The answer, of course, is not to rely on technical solutions, but to improve editors' understanding of what alt does and help them write better alternative text (alt + caption taken together).

I could go on, but it would be unfair to the Wikimania presentation, which had all the right intentions, and did help to raise awareness of problems. I'd say we should consider the presentation as a good starting point for further development, and keep the discussion going. --RexxS (talk) 16:29, 29 July 2012 (UTC)

Okay, thanks for sharing your thoughts. :-)

From what I know, Eduard Klein based his conference on what he saw of the German Wikipedia. The German Wikipedia doesn't have an active accessibility project, and is lacking in accessibility compared to English and French Wikipedias. I don't think the author was aware that other communities have experience in the field, and their set of guidelines. I did send him a mail to tell him what we are doing, but did not get a reply yet.

Accesskeys are a good example of a special case where it's not relevant to follow the traditional accessibility approach in Wikipedia's case. The need for accesskeys was removed in WCAG 2.0. The good approach would be to conform to W3C ATAG guidelines, a set of guidelines for authoring tools - very relevant in Wikipedia's case. ATAG recommends using customizable accesskeys, in order to prevent conflict with browsers key and screen reader keys.

Just like RexxS, I think it's always good to have such conferences raise awareness among our community. My hope was not to improve our guidelines according to this conference, because accessibility for a large-scale wiki is a very special and complex case. However, I do hope that this conference helped to reach the higher-ups from the Wikimedia Foundation. There are things we cannot improve ourselves, without the help of an accessibility expert working with the MediaWiki developers. So the WMF should employ an accessibility expert, and I hope this conference helped to promote this idea.

Anyway, I think that the next goal for our accessibility project would be to convince the WMF to employ an expert. The WMF has been hiring a lot of staff recently, and I think they are ready to include accessibility. Cheers, Dodoïste (talk) 17:22, 29 July 2012 (UTC)

In just over a week's time, I hope to be appointing a Developer for Wikimedia UK, and I'll do my best to ensure they have expertise in accessibility, which should help us benefit the English Wikipedia as well as our other projects. I expect the WMF will be thinking along similar lines, but we could always drop a line to the WMF Board to help push the case. --RexxS (talk) 17:57, 29 July 2012 (UTC)

It would be very good if we can make a set of 'recommendations' for creating accessible code that includes at least the stuff almost everyone agrees upon. In my personal experience the biggest problem for the developers is "what set of rules am I supposed to follow". —TheDJ (talk • contribs) 18:42, 29 July 2012 (UTC)

@RexxS: Sounds great! What kind of work would the developer be assigned to?

@TheDJ: Sure, we should write guidelines for developers. But it's not that easy, because I don't see what projects you are working on, with which tools you work, what developement schedule you use... I don't know how many developers would be interested to take accessibility into account. Maybe some never heard about accessibility. I feel like a total outsider, I can't tell what guidelines would benefit you the most. Well, I guess one good guideline would be to test keyboard focus and keyboard operability. That's the point that was most lacking in recent developments. I would have to do some research to find other common mistakes. But that's definitely one way to move forward. Cheers, Dodoïste (talk) 19:53, 29 July 2012 (UTC)

That would be a very good start. I would also find it useful if it weren't so easy to create lists with improper HTML, which can currently be done by simply adding an extra line break between each list item. Graham87 02:27, 30 July 2012 (UTC)

Talk pages (not this one) being one of the worst cases... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 30 July 2012 (UTC)

@Dodoiste I have started an Accessibility_guide_for_developers that I intend to fill out with some of this information. If it's good enough, I'm sure that WMF is interested to have a required session for all their devs on this. I have some ideas at least. —TheDJ (talk • contribs) 10:31, 30 July 2012 (UTC)

There are a number of long-standing MediaWiki bugs on Bugzilla, which will have accessibility benefits if resolved. Perhaps we might raise awareness of them (and lobby to ensure that any fixes are promptly deployed on Wikipedia)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 30 July 2012 (UTC)

I've actually been going trough most of them over the past hours, and almost all open issues, have very good reasons of not being fixed yet. Headers and landmark roles seem to actually be things that we could fix now, but the rest is often still rather murky. However, i also looked at the documents of earlier reviews, and it seems that about half of the issues of the older reviews have been fixed troughout the years. Progress has been made, it's just slow, and I see that some mistakes are made all over again in newer software development efforts. —TheDJ (talk • contribs) 14:01, 30 July 2012 (UTC)

I've left a description about the keyboard navigation requirement, at the talk page of your summary for developers. It's really efficient! I fear I'm not able to shorten explanations this far, I'll let you do it if you don't mind. I'll think about other improvements for this page, but it's already good. Thanks! Dodoïste (talk) 00:09, 1 August 2012 (UTC)

The presentation is now available on YouTube; it starts at 25:57. I made a comment there but forgot to introduce myself. Graham87 14:06, 22 August 2012 (UTC)

Thanks for the link Graham. :-) Dodoïste (talk) 16:40, 22 August 2012 (UTC)

Awareness

In addition to the above, I think we also need to raise awareness of accessibility issues, and solutions, on Wikipedia, in two ways:

1. We should have an accessibility statement, for readers (and editors) of Wikipedia who have accessibility needs, to tell them what features are available to them. This should appear on the main page, an in the chrome of every page, perhaps under the "interaction" heading.
2. A link to a simple page, including a "top ten" (say) basic accessibility tips or FAQ for editors (like this)), and linking to this project, to be included in welcome templates and editor guides.

Thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:58, 30 July 2012 (UTC)

1) An accessibilIy statement is a very good idea, I suggest to place it in the footer because it's the standard. Here is a good reference I found: "writing an accessibility statement", Léonie Watson. We are improving accessibility of the website, slowly because the number of articles is huge - 4 million pages needs to be improved. But the turtle will eventually cross the finish line. :-) Another key point is the ability to report accessibility issues.

2) I believe our guidelines and techniques are no mature enough to reach a broader audience of volunteers. Most guidelines require experience with wikicode, and experience with Wikipedia. Some editors should make accessible edits just by copying good examples, without knowing they are improving accessibility. Accessibility is more efficient and accepted when it is transparent, rather than whem it is yet another constraint wheigthing on the editor's conscience. Cheers, Dodoïste (talk) 18:31, 31 July 2012 (UTC)

Did you man to say "noT mature enough" or "noW mature enough"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 3 August 2012 (UTC)

I meant "not mature enough". Also, about the accessibility statement: does it make sense to announce that we are striving for accessibility, when the WMF is not yet involved and might deploy new features that impair accessibility? The WMF do care about accessibility, but is not yet commited to accessibility. Thus, there is a risk that new developments would contradict our statement. How should we adress this issue? Dodoïste (talk) 16:55, 3 August 2012 (UTC)

Screen magnifier userbox

Finally got round to something I've been meaning to do for ages. After at last finding a public domain image for it, there's now a userbox for anyone who uses screen magnifiers such as Lunar and others at {{User screen magnifier}}. Apologies for the delay, and feel free to replace the image if you find a better one. Cheers Paul MacDermott (talk) 16:08, 18 August 2012 (UTC)

This user edits with the help of a screen magnifier

R-phrase template

I have concerns about the use and accessibility of {{R-phrase}}. Please join the discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:18, 20 August 2012 (UTC)

Accessibility of sigs

The accessibility of user sigs is being discussed at Wikipedia talk:Signatures#Simplifying signatures. Your views would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 4 September 2012 (UTC)

I've fixed the link. Graham87 14:21, 4 September 2012 (UTC)

Tennis events colours

There's an issue with colours on {{Tennis events 2}}; please see Template talk:Tennis events 2#Colours. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 7 September 2012 (UTC)

Struck-though text

There's a discussion of use of struck-through text, at Talk:Nanjing Dajiaochang Airport#Struck-through content. Your views would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:04, 19 September 2012 (UTC)

Would someone double check my signature to ensure accessibility?

Would someone double check my signature to ensure accessibility? I was messing around with it today and came up with this. Thanks--Go Phightins! 22:03, 14 October 2012 (UTC)

According to this tool, the  green text  has a contrast ratio of 4.98 so is WCAG 2 AA Compliant, but not WCAG 2 AAA Compliant; the  blue text  is better, with a contrast ratio of 8.33 so is WCAG 2 AAA Compliant; but the  red text  has a contrast ratio of only 3.88 so is not even WCAG 2 AA Compliant. --Redrose64 (talk) 22:23, 14 October 2012 (UTC)

I want to use three different colors to show the links to the three different pages. What colors would be better? Go Phightins! 22:26, 14 October 2012 (UTC)

(edit conflict) I wouldn't like to suggest any specific colours, but I would recommend going to the tool I just mentioned and playing with that. Start off by going to the box headed Background Colour:, and after the # sign, enter the value F8FCFF which is the standard background for talk pages like this. Then, in the box headed Foreground Colour:, set a colour value to use as your starting point (your present colours are green = #008000; blue = #0000FF; red = #FF0000), then pull the sliders in the same box around (leave the sliders under Background Colour: alone) until you find something that you like, and which shows a Contrast Ratio of 7.00 or higher.

For example, the green that you're presently using has a value of #008000; if you enter that under Foreground Colour:, and pull either the Green slider or the Value % slider a little to the left, you'll find that the WCAG 2 AAA Compliant indicator flips from "NO" to "YES" when the Contrast Ratio passes 7.00. One value which suits this is #006600 which  looks like this . --Redrose64 (talk) 22:47, 14 October 2012 (UTC)

Does making it bold or italic change anything such as this: Go Phightins! 22:33, 14 October 2012 (UTC)

Or this? Go Phightins! 22:39, 14 October 2012 (UTC)

Italics are not shown as making a difference; boldface is only significant at 14-point or larger, which as you can see from my demo, is not our normal font size. --Redrose64 (talk) 22:59, 14 October 2012 (UTC)

Hmmm, I'll play around with it. Thanks for your help--Go Phightins! 23:02, 14 October 2012 (UTC)

If I'm not mistaking, this is compliant. Thanks--Go Phightins! 00:24, 15 October 2012 (UTC)

23:00 UTC is midnight in the UK, and I went to bed. Anyway, the  blue text  is unchanged, and we already know that it is compliant; the  red text  has a contrast ratio of 4.56 (up from 3.88) so is now WCAG 2 AA Compliant, but still not WCAG 2 AAA Compliant; the  green text  has a contrast ratio of 4.67 (down from 4.98) so is WCAG 2 AA Compliant, but not WCAG 2 AAA Compliant. In summary: the red is an improvement, but not perfect; the green is slightly worse than before.

Try these values:  blue text  as present;  red text  #B20000 (contrast ratio 7.04);  green text  #006600 (contrast ratio 7.02). If you force a white background, and throw in a little blue, you can make the  red text  #B60017 (7.00) and  green text  #006821 (7.00) which are slightly lighter. However, this will take your sig over the 255-character limit, so you need to lose something - I suggest the boldface:

<span style="background-color:white">[[User:Go Phightins!|<span style="color:blue">Go</span>]] [[User talk:Go Phightins!|<span style="color:#B60017">''Phightins''</span>]][[Special:Contributions/Go_Phightins!|<span style="color:#006821">!</span>]]</span>

which looks like this: Go Phightins! and is 254 characters. --Redrose64 (talk) 16:39, 15 October 2012 (UTC)

International Standard

WCAG 2.0 is now recognised by the International Standards Organization, as ISO/IEC 40500:2012 (see [2]). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 23 October 2012 (UTC)

Thanks for the news. While it is certainly a good thing, a professional told me that the impact of this ISO norm might be limited. HTML is also an ISO norm, it did not prevent it from being misused. But it's still a step forward. Dodoïste (talk) 22:16, 31 October 2012 (UTC)

Wikidata:Accessibility

Those of you interested in our new Wikidata project might like to know that I started an [accessibility page there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 31 October 2012 (UTC)

Thanks. That is certainly an smart thing to do. Since it's a new project, it does not yet have habits, templates, lots of content to change... It is a great occasion to do things right from the start. Dodoïste (talk) 22:18, 31 October 2012 (UTC)

Although... since most of the contents so far is a collection of interwiki links, there seems to be little to do with the community. Maybe once they start to provide other kinds of content in there. Or we should work with Wikidata developers? Dodoïste (talk) 21:01, 4 November 2012 (UTC)

Video subtitles - timed text

There is a new feature recently deployed, called Timed Text, that provides subtitles for audio and video. As described in this week's signpost technology report. There is much to be done in this regard. But first I would welcome anyone's effort to try this feature, understand how it works and all. There is no help page for the moment, as far as I know.

We should also investigate several important questions.

1. How to switch subtitles languages?
2. What about closed captions for the deaf community?
3. Is the feature accessible with a keyboard - will a blind user be able to use it?
4. Can the subtitles be read aloud easily with a screen reader?
5. Will blind users need a separate or additional description of the video to understand it?

Example

Tracked in Phabricator
Task T43694

Tracked in Phabricator
Task T43695

I guess I should ask the techs guys at the village pump/technical, in a few days. Especially since some developers are checking the page regularly. Dodoïste (talk) 13:34, 2 November 2012 (UTC)

1. If there are multiple languages uploaded, you will have a CC menu where you can switch between languages:
2. There is currently no explicit distinction between subtitling and subtitling for the deaf. This could be added quite easily though.
3. It's not keyboard accessible. Actually one of the bigger issues that I have had with this project from the start.
4. No not really.
5. Depends a bit on 2. —TheDJ (talk • contribs) 14:07, 2 November 2012 (UTC)

I found a help page: commons:Commons:Video#Subtitles_and_closed_captioning. I'm going to update the accessibility tutorial.

Thanks for your bug reports and your answers TheDJ. :-) Dodoïste (talk) 12:42, 4 November 2012 (UTC)

WAI-ARIA in MediaWiki

I've made a patch that add the "role" attribute to most importants parts of the page. But I'm not an accessiblity specialist, so if someone can verify I haven't made any mistake it would be amazing ! Tpt (talk) 07:20, 3 November 2012 (UTC)

Thanks for your work. Unfortunately I'm not an accessibility specialist either, and I've not been taught much about WAI-ARIA. I'm going to ask RexxS for advice. Cheers, Dodoïste (talk) 16:47, 3 November 2012 (UTC)

The patch looks fine to me, Tpt, although I'm no expert (just been around a long time!). The problem you get with XHTML validation is that the tool hasn't caught up with the latest W3C recommendations: WAI-ARIA 1.0 Primer 2.1.4 and WAI-ARIA 1.0 Primer 2.2 (as you probably already know). Hashar simply needs to be pointed to http://www.w3.org/WAI/intro/aria.php and asked to read up. Cheers --RexxS (talk) 20:03, 3 November 2012 (UTC) (Cet utilisateur peut contribuer avec un niveau intermédiaire en français)

Please do not patronize. —TheDJ (talk • contribs) 13:34, 4 November 2012 (UTC)

Don't be an ass, DJ. Tpt (who is not a native English speaker) was concerned by the comments on his patch. One of those from Hashar ( Line 9 here ) was "It would be nice to give a summary about what ARIA is". Now I think we need to be grateful to Tpt for the work he does, not ask him to work further outside of his native language, so if Hashar understands WAI-ARIA, then he needs to consider doing that sort of job himself. If not, then the link I provided will help. --RexxS (talk) 20:11, 4 November 2012 (UTC)

Template:Fraction

I believe that Template:Fraction fails MOS:FRAC and WP:NOSYMBOLS because of its use of Unicode fractions, and also its use of the Unicode character ⅟ to represent certain fractions with unit numerator. Consider the following:

• {{fraction|1|2}} → 1⁄2
• {{fraction|1|3}} → 1⁄3
• {{fraction|1|4}} → 1⁄4
• {{fraction|3|4}} → 3⁄4
• {{fraction|1|5}} → 1⁄5
• {{fraction|1|6}} → 1⁄6
• {{fraction|1|8}} → 1⁄8

Potentially, constructs such as these could yield any of the following: ½, ⅓, ⅔, ¼, ¾, ⅕, ⅖, ⅗, ⅘, ⅙, ⅚, ⅛, ⅜, ⅝, ⅞.

Constructs where the numerator is 1 but the denominator is not 2, 3, 4, 5, 6 or 8 yield the ⅟ character:

• {{fraction|1|7}} → 1⁄7
• {{fraction|1|9}} → 1⁄9
• {{fraction|1|10}} → 1⁄10
• {{fraction|1|100}} → 1⁄100
• {{fraction|1|1000}} → 1⁄1000

But other fractions where the denominator is not 2, 3, 4, 5, 6 or 8 come out like this:

• {{fraction|2|7}} → 2⁄7
• {{fraction|2|9}} → 2⁄9
• {{fraction|2|10}} → 2⁄10
• {{fraction|2|100}} → 2⁄100
• {{fraction|2|1000}} → 2⁄1000

By contrast, the {{frac}} template consistently uses <sup></sup>&frasl;<sub></sub> as in:

• {{frac|1|2}} → 1⁄2
• {{frac|1|7}} → 1⁄7
• {{frac|2|7}} → 2⁄7

etc. --Redrose64 (talk) 21:59, 5 July 2012 (UTC)

I still don't understand why commonly-used fraction characters aren't supposed to be used. First of all, calling them "Unicode" is incorrect; vulgar one-half, one-quarter, and three-quarters are part of ISO-8859-1. I'd like somebody to give me an example of a single browser or screen-reader nowadays that won't support them. It's silly that we're still using these hacky workarounds.

I agree with your other point, however. The fractions that don't have characters should be formatted more consistently. That would be an easy fix in the template.—Chowbok ☠ 10:14, 6 July 2012 (UTC)

Redrose64's reasoning is correct. But I feel I am not the right person to answer this question, as I don't use a screen reader everyday. We should ask for user:Graham87's advice on the matter. Unfortunately, he just left to attend Wikimania, and won't be back before some time.

In the meantime, I tested using Apple's VoiceOver. I was able to read everything, but not too well. ½ was correctly read as "one-half"; same with the following fractions of this type. But as I tried to read the whole list "½ ⅓ ⅔ ¼ ¾ ⅕ ⅖ ⅗ ⅘ ⅙ ⅚ ⅛ ⅜ ⅝ ⅞", VoiceOver crashed. I tried with my Chrome native text to speech, it crashed and I had to restart Chrome. Oh boy.

1⁄1000 behaves weirdly. It is read "one one thousand", but no indication of it being a fraction (or am I not used to hear english fractions?). If I read "⅟" alone it is read "one fraction symbol".

2⁄7 is read as "two slash three".

3⁄4 is read as "three four".

Frankly, I do not know how to interpret these result. Plus, this is only VoiceOver. Hoes does JAWS and NVDA behave? I don't know. Let's wait before we take a decision. Dodoïste (talk) 11:43, 6 July 2012 (UTC)

Both JAWS and NVDA read only the ISO 8859-1 characters correctly, not the Unicode ones. I'm writing this from a lovely hotel room in Toronto. I plan to check my watchlist every few days if I can. Graham87 02:12, 8 July 2012 (UTC)

Why do we need two templates, {{fraction}} and {{frac}}? How are the majority of editors supposed to understand the difference between them? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:06, 26 July 2012 (UTC)

Apparently we now have three, see {{Sfrac}}. --Redrose64 (talk) 15:09, 26 November 2012 (UTC)

Potential collaboration/taskforce/WikiProject

Gauging interest I am posting the same message to Wikipedia talk:WikiProject Images and Media, Wikipedia talk:WikiProject Usability, and Wikipedia talk:WikiProject Accessibility to see if there is interest in a collaboration regarding adding subtitles to audio. Recently, the TimedText namespace became active and I decided to test it out with two subtitles: TimedText:Sufjan_Stevens_-_Casimir_Pulaski_Day.ogg.en.srt for File:Sufjan Stevens - Casimir Pulaski Day.ogg and TimedText:They_Are_Night_Zombies!!_-_Sufjan_Stevens_-_clip.ogg.en.srt for File:They Are Night Zombies!! - Sufjan Stevens - clip.ogg (someone else has created TimedText:Björk_-_Mutual_Core_sample.ogg.en.srt for File:Björk - Mutual Core sample.ogg as well.) I also worked with Rich Farmbrough (talk · contribs) to create {{Subtitles}} and categorize audio files with subtitles. This leaves 7,087 audio and video files which lack subtitles (note that not all need them as some have no spoken audio.) Does anyone want to help me? —Justin (koavf)❤T☮C☺M☯ 19:18, 5 November 2012 (UTC)

Template:Access icon

Template:Access icon has been nominated for deletion. Please comment at Wikipedia:Templates for discussion/Log/2012 November 12#Template:Access icon. --Redrose64 (talk) 16:00, 12 November 2012 (UTC)

Wikivoyage:Accessibility

Like Wikidata:Accessibility, above, I have added a Wikivoyage:Accessibility project to Wikivoyage. No doubt our new colleagues there will appreciate your input. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:36, 14 November 2012 (UTC)

FAC review headings

I've raised a concern about WP:FAC, which says "Please do not split FAC review pages into subsections using header code (if necessary, embolden headings)", as this is contrary to WCAG. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:47, 21 December 2012 (UTC)

RfC: Section headings for horizontal navigation templates

Please comment on accessibility considerations, at Wikipedia talk:Categories, lists, and navigation templates#RfC: Section headings for horizontal navigation templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:04, 28 December 2012 (UTC)

Headings in Portal:Current events

I've raised a concern about sub-headings in Portal:Current events, which are formatted using semi-colons. Your comments would be appreciated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:32, 28 December 2012 (UTC)

Question regarding "Disabling conditions" and competence of editors

Please see here for a question I believe may well be relevant to matters of accessibility of wikipedia editing by certain editors, known and unknown. Any response would be welcome. John Carter (talk) 02:07, 10 January 2013 (UTC)

Inline tags

Some in the German Wikipedia are discussing (at length!) whether they should introduce a template, equivalent to Citation needed. A contra-argument that has been raised now is the possible accessability barrier of inline tags, like those emitted by {{Citation needed}}. However, there seems to be limited experience there to determine whether that is so or not. Does the output of this template have an effect on accessability? Can screenreaders be configured to lessen the effect? Was there evere a discussion where accessability issues were raised against inline templates? -- Michael Bednarek (talk) 05:24, 10 January 2013 (UTC)

There's very little wrong with inline tags from an accessibility perspective. The links provided with the tags are a little annoying for screen reader users (as they should be), but its possible to lessen the effect of that issue if needed. Graham87 12:48, 10 January 2013 (UTC)

Accessibility and equality as core policies

Further to the above: I propose that we add a commitment to accessibility and equality to the Five pillars. Please join discussion at Wikipedia talk:Five pillars#Accessibility and equality. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:30, 11 January 2013 (UTC)

Keyboard accessibility of article feedback tool

I cannot find any way to give star ratings to articles without using a mouse. The rating widgets don't seem to be in the tab order in any of the browsers I've tried; additionally, although the headings (trustworthy, objective, etc.) are visible to VoiceOver on OS X, there's no way to assign a rating to any of them that I can find. --Codeman38 (talk) 03:07, 11 January 2013 (UTC)

Yes, it's not very accessible. But that doesn't matter so much, because it will soon be replaced by version 5 of the tool, which has its own accessibility issues but is more accessible than version 4. Graham87 06:02, 11 January 2013 (UTC)

Yes. The problem is WMF developers never check for accessibility issues when producing features. They just don't have this necessary step included in their workflow. I'm wondering how to deal with this. Currently, there are not many cases of this happening. But as the developers are making an increasing number of tools and other changes it might become a nightmare. Dodoïste (talk) 08:32, 11 January 2013 (UTC)

Actually the developers do consider it. It's not a distinct element of the workflow in terms of "we spend features requirements time working out precisely what will/could wrong", but trying to make things accessible is a pretty accepted part of development (I'd argue that "there are not many cases of this happening" is possibly evidence not of negligence but of competence). Okeyes (WMF) (talk) 14:43, 11 January 2013 (UTC)

Yes, this is also what I intended to say. My apologies, I should have included more details in my previous comment. We have interacted with several developers so far, and many seems interested and compelled to produce accessible software. We do notice that common accessibility requirements that most developers are aware of are taken into account spontaneously. This should be praised as an effort from the developers. They care. :-)

What I intended to say, is that they can only do so much without expertise. In the current development process, it shows that there are no formal verification using a rigorous methodology. Such a methodology would be 1) using the WCAG check-list or associated tools, or 2) asking for independent review or 3) hiring an accessibility specialist to work with the developers. I would encourage the third, as an internal specialist would allow for a fluid and easy development process. It would also improve the skills of the WMF developers regarding accessibility. Thanks for reading this, Okeyes. I hope it helps. Dodoïste (talk) 15:11, 11 January 2013 (UTC)

It does :). Obviously I don't have the authority to hire anyone (alas, alack. If I did, I'd be retired in Mali with four people doing my job in SF ;p) so I can't help directly on No. 3. I think the closest we have to an accessibility specialist, for AFT5 at least, is Graham :). He's always wonderfully helpful. I'm actually setting up a meeting with the head of features engineering anyway - I'll see if I can work the WCAG checklist in. Okeyes (WMF) (talk) 15:53, 11 January 2013 (UTC)

That would be a good step; but a better one would be to ensure that every new feature is tested by a variety of people with special access needs; including., for example, people like Graham, who use screen readers, but also people who have limited sight and so require very large text, and people with dexterity limitations who cannot sue a conventional mouse. That might mean volunteer Wikimedians; or outsourcing to a specialist testing company who have such people on their books. We ought to add accessibility to the 5 pillars; perhaps adding under the third ("Wikipedia is free content that anyone can read, edit, use, modify, and distribute"); possibly as a new, 6th, item, with gender and other equality matters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:12, 11 January 2013 (UTC)

Nah, Andy. For several reasons, it is not very efficient to test each new feature with a variety of users. And it can't be included smoothly in the development process. In most cases it is sufficient to conform to a check-list, because the needs and the solutions are standardised. However, for special and complex cases like building a visual editor it would be necessary to test with a blind user.

@Okeyes: Thanks for creating this opportunity. If you favor the WCAG check-list solution, I heavily recommend the use of the summarized and simplified check-list made by WebAim experts (PDF version). Developers often perceive WCAG as an overwhelming mountain of guidelines that only accessibility experts are able to use. Rightfully so. Webaim summarized it all in a 6 page document that is easy to read. It is meant to be a cheatsheet to use when in doubt. It is best that developers receive a 1 day introduction to WCAG methodology before using such a check-list. There are many accessibility experts who provide accessibility training anywhere it the U.S. You should be able to find one in San Francisco. Cheers, Dodoïste (talk) 00:37, 12 January 2013 (UTC)

Sweet! I'm not based in SF myself, but I'll see what progress I can get/what checks they do now :). Okeyes (WMF) (talk) 16:13, 17 January 2013 (UTC)

Template:Track listing

I'm sure this question has been asked of every template under the sun, but I'm far from proficient in judging these things. A recent peer review threw up the question of whether Template:Track listing (more specifically, its use in Laborintus II, which is a standard example) meets MOS:ACCESS/MOS:DTT. The template itself nests a few other templates which makes it a little tricky for me to wrap my head around what I'm meant to be looking for. From what I can make out, though, it does seem to meet MOS:DTT by giving the appropriate scope qualities for its rows and columns, but to be honest I don't know what to look for after that. If anyone happens to know off-hand that would be great, or even if there is a decent free screen-reader I could be pointed towards to test how it turns out, that would also be fantastic. Thanks in advance to anyone able to help with this one. GRAPPLE X 23:55, 6 February 2013 (UTC)

The Template:Track listing was made fairly accessible on march 2012. Most of its inclusions should meet MOS:DTT, as far as I can tell. Its use in Laborintus II is standard thus accessible.

This template could still be improved in theory, but the benefits would not be obvious in regards to the costs. Thus "track listing" is good enough as it is now. Thanks for your concern, Dodoïste (talk) 17:12, 8 February 2013 (UTC)

Happy days, thanks very much for the response. GRAPPLE X 23:47, 8 February 2013 (UTC)

The change I have suggested at Template talk:Track listing#Album_name + artist is still needed, both to improve accessibility, and to make it possible for the template to emit useful metadata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:24, 20 February 2013 (UTC)

Election candidate table rows

Please review the accessibility of the table rows in, for example, Pennsylvania Senate elections, 2008. They use {{Election box inline incumbent}}, {{Election box inline candidate with party link no change}} etc. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:00, 20 February 2013 (UTC)

Nice catch. This table has significant issues, ones that are very common in this type of articles. Good news are the templates should allow for easy and massive improvements. Will try to look into this today, if I can. Cheers, Dodoïste (talk) 09:27, 23 February 2013 (UTC)

If found a potential solution, what do you think of this cell border-left color proposal? Cheers, Dodoïste (talk) 13:48, 23 February 2013 (UTC)

Alt attribute review

What's the best text to use in the alt attribute of the image on Northampton Museum and Art Gallery? Please comment on that article's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:05, 20 February 2013 (UTC)

Color contrast ratio template

There is a new Wiki template for calculating the W3C recco'd contrast ratio of a color pair, described at Wikipedia:Lua requests § Check if a pair of colors has enough contrast for acessbiility. —[AlanM1(talk)]— 18:10, 1 March 2013 (UTC)

Thank you again for creating this template! Helder 19:40, 1 March 2013 (UTC)

Categorization of pages with contrast problems

Hi!

What do you think of using the (new) {{Color contrast ratio}} to check if the two colors provided to {{Font color}} have an appropriated contrast, and if not put the page in some maintenance category, maybe a subcat of Category:Articles with accessibility problems? Helder 19:40, 1 March 2013 (UTC)

I can see this being very useful. for templates that explicitly ask for the fg and bg colour, we could certainly add this as a way to track situations with poor contrast. for other situations, like navboxes, we would need a way to extract the background and foreground colour from the style statement. I suppose this is also possible using string matching? also, is there a way to get this to work for named colours, like "white", "green", "black"? you would need a table with the list of html colours. currently these resolve as an error message. Frietjes (talk) 22:42, 1 March 2013 (UTC)

 Done The 16 HTML colors and CSS "orange" are now supported (case-insensitive). —[AlanM1(talk)]— 00:26, 2 March 2013 (UTC)

Both Chrome and Firefox are able to "Inspect element" from a right-click menu which will give you the color/background-color values of any text with a little scanning. The only point I'd make is that WCAG AAA standards demand a ratio >7 (or <0.143) for normal sized-text (4.5/0.22 only meets the AA standard for normal text), and I'd rather we aimed for AAA-compliance where possible. I've yet to see a good reason put forward why our articles should have any difficulty in reaching the higher standard in these cases. --RexxS (talk) 00:15, 2 March 2013 (UTC)

Sure, but if we can reach AA level consistently it will already be a great achievement. AAA where possible, but we can't achieve AAA level consistently. You know how Wikipedians love to be consistent, don't you? I believe aiming at AAA level is risky as it could lead to unnecessary disputes. Dodoïste (talk) 09:24, 2 March 2013 (UTC)

This is one of the areas where it's not so difficult to reach AAA level if editors are aware of what is needed, and therefore we should be raising awareness as much as possible. Let me give you a real example. In the article Alpha Centauri there is a table with this header:

Companion (in order from star)	Mass	Semimajor axis (AU)	Orbital period (days)	Eccentricity	Radius

With monobook skin, the contrast ratio between the hyperlinked text (#002BB8) and its background (#A0B0FF) is 4.980568493291 (note: we don't need that much precision) which meets AA and fails AAA. But if the background colour is changed to #CAD4FF the table header becomes:

Companion (in order from star)	Mass	Semimajor axis (AU)	Orbital period (days)	Eccentricity	Radius

which yields a contrast ratio of 7.0534335018797, meeting AAA and clearly more legible to me, although it has the same hue. Now can anybody supply a sensible reason why the latter is in any way inferior to the former? If the designers of the template that produces the header were aware of the WCAG AAA level requirements before they started, then I have little doubt that they would have chosen a higher contrast in the first place.

I agree there are many areas where achieving AAA would require far more effort than can mustered at present, but this isn't one of them. I'd suggest that the documentation for {{Color contrast ratio}} might mention the ratio of 7.0:1 as the WCAG AAA standard, which would hopefully encourage clueful editors to adopt that as part of their design. --RexxS (talk) 14:44, 2 March 2013 (UTC)

The template documentation was improved a little to show which color combinations are desirable. Helder 13:46, 29 March 2013 (UTC)

RFC: templates for specific accessibility problems?

Anyone thinks it's worth adding templates for specific self-explanatory accessibility problems? Example: Blind user notices image in entry without alt= (or other as appropriate) description, flags it. Unless what should go in the description is unclear to sighted editors familiar with entry topic, there should be no need for additional talk page discussion. — Preceding unsigned comment added by PauAmma (talk • contribs) 21:54, 17 March 2013 (UTC)

Responding to the specific example: wouldn't that be a bit of an eyesore, considering that almost all images lack alt text? See a relevant conversation on my talk page. I could just imagine that template causing lots of wiki-drama, because there'd be no way to restrict use of that template to blind people; I'm sure *somebody* would go around trying to add it everywhere. Another problem with templates like that would be advertising them to the right people. Most readers don't edit, and most new editors would have no idea how to use templates. Graham87 01:45, 18 March 2013 (UTC)

Fair enough wrt the specific example and the advertising/educating hurdles you mention. I still think a quick way to flag specific problems may be useful even then, although I'm not sure what form it should take considering what you said. Any idea? The Crab Who Played With The Sea (talk) 18:51, 14 April 2013 (UTC)

Probably a template that has no visible output, but adds the page to a (hidden?) category like Category:Unclassified articles missing image alternative text. Browsing that category would keep the WikiGnomes in work well into the next decade.

Addendum: Template:Alternative text missing already exists and does the job I suggested. --RexxS (talk) 19:41, 14 April 2013 (UTC)

Works for me, thanks. The Crab Who Played With The Sea (talk) 19:53, 14 April 2013 (UTC)

RFC: cleaning up and expanding the list of userbox disability templates

Template:User aspie redirects to Template:User Asperger: is there a reason to keep it on the list?

Also, which templates are missing from the list? (Existing ones or ones to be created.) Off the top of my head, I can think of depression, diabetes (all types), motor disabilities (all types/variants, including congenital/acquired/progressive if relevant), pain-related conditions, and acquired/progressive mental disabilities like Alzheimer's, but there are certainly others that should be included. — Preceding unsigned comment added by PauAmma (talk • contribs) 14:40, 31 March 2013 (UTC)

Make accessibility love, not edit war

Guys, can you please step back and take a break? I'm sure there's enough accessibility problems on Wikipedia that wasting time edit-warring about below vs. hereafter vs. whatever shouldn't be a priority. The Crab Who Played With The Sea (talk) 18:21, 14 April 2013 (UTC)

Indeed, although I can see that we ought to be setting the best possible example where we can on these pages. I actually thought that Nnemo's latest attempt, "... to the following list", was far better than either "below" or "hereafter", but I'm not going to war over it. --RexxS (talk) 19:27, 14 April 2013 (UTC)

Thank you, RexxS. “To the following list” is clearer than the other tries that were there before. --Nnemo (talk) 20:04, 14 April 2013 (UTC)

The beginning of this discussion is on my talk page. --Nnemo (talk) 20:06, 14 April 2013 (UTC)

Accessibility of new notifications system

I have raised a concern about the accessibility of the new Notifications feature]] for screen readers. It'd be best to make any substantial comments about it in the relevant bug report. Graham87 13:16, 4 May 2013 (UTC)

Coloured links and █ characters

At Wikipedia talk:WikiProject Trains#Additional comments (and the end of the immediately preceding section) there is a discussion about the accessibility of text and links in the colours of lines used on rail system maps, and about using things like coloured table cells and coloured block characters like █ as alternatives, especially how screen readers deal with such things. Please could someone with knowledge of this comment in that discussion, thanks. Thryduulf (talk) 12:22, 5 May 2013 (UTC)

HTML emails

There is a proposal to make Wikipedia's notification emails use HTML, with no user option to prevent that. Please comment at Wikipedia talk:Notifications#HTML email. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 16 May 2013 (UTC)

width:5px;font-size:1%;

How accessible is bodystyle=width:5px;font-size:1%; on an infobox? See, for example, St Mary's, Bryanston Square. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 28 May 2013 (UTC)

Why does it need to be that small? Is Nikkimaria trying to create a white dwarf? --Redrose64 (talk) 18:36, 28 May 2013 (UTC)

I changed it to a collapsed infobox, which I know Andy doesn't like either, but will see how long that lasts. Frietjes (talk) 21:12, 28 May 2013 (UTC)

I don't think anyone who understands accessibility likes collapsed content.

Collapsing was a compromise solution to deal with articles that had a multitude of (or bulky) navboxes. Collapsing should never have escaped from its use in navboxes. It's being used in infoboxes for entirely the wrong reasons - akin to the perennial suggestion that we put "spoilers" in a collapsed section. (I did find the long long discussion at TfD after it had closed, but I do not wish to rehash it here/now).

Yes, font-size:1% it utterly inaccessible, and I will assume it was a bad joke. There are lots of those around this topic. Let's try not to bludgeon the carcass of this one. –Quiddity (talk) 23:19, 28 May 2013 (UTC)

VisualEditor is coming

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:03, 7 June 2013 (UTC)

RFC at WT:ACCESS

There is a discussion at Wikipedia talk:Manual of Style/Accessibility#RfC: What is the scope of this guideline? about whether accessibility should be encouraged for talk pages, project pages, etc., or just for articles. WhatamIdoing (talk) 23:31, 6 June 2013 (UTC)

I refuse to take part, after certain people made demonstrably untrue statements about my edits. I'm not going to give any credence to their lies and slander. --Redrose64 (talk) 18:47, 7 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:39, 16 June 2013 (UTC)

Chinese surnames

There is a move to disambiguate by Chinese characters in the article title. I would assume that this would cause problems. Anything to add here? --Rob Sinden (talk) 09:19, 27 June 2013 (UTC)

Area code box

{{Area code box}} is a geographic navbox, using a table layout for North, South, East and West links. I seem to recall we've replaced or improved such templates in the past, for accessibility reasons. What should we do in this case? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:05, 29 June 2013 (UTC)

seems like we should also check {{geographic location}}? the directions are labelled, which seems to me that it is already an improvement over the geographic location template. Frietjes (talk) 18:28, 29 June 2013 (UTC)

Yes, the area code box is usable with JAWS precisely *because* the directions are labeled; the geographical location template isn't. Graham87 07:01, 30 June 2013 (UTC)

About the accessibility css.

Although personally not photophobic, I believed text color like #EEEECC would be better than eyes compared to the current green color. How can I change the css file to test it? C933103 (talk) 16:15, 20 July 2013 (UTC)

Open up Special:MyPage/skin.css and add the line to your personal css file. you can find most of the defaults in MediaWiki:Common.css. you can see an example used to override the colour of navboxes and colour redirects green in User:Frietjes/vector.css. Frietjes (talk) 17:05, 20 July 2013 (UTC)

Colour contrast in two infoboxes

Please see Template talk:Infobox vice-regal#Colours and Template talk:Infobox ministerial office#Colours. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:02, 24 July 2013 (UTC)

Shortcuts

I've made the shortcuts WP:WCAG and WT:WCAG for this project and talk page pair. They should be easy to remember! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:28, 6 August 2013 (UTC)

Convert template abbreviatons

I've started a conversation about abbreviation markup, for the {{Convert}} template. Your views would be welcome there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:31, 6 August 2013 (UTC)