Wikipedia talk:WikiProject Accessibility

Collaborations WikiProjects Accessibility  Main discussion page

WikiProject Accessibility menu
What is accessibility? FAQ and common pitfalls Main discussion page
Guidelines for articles Dos and don'ts Manual of Style/Accessibility Alternative text for images Data tables tutorial Articles task forces
Guidelines for templates Template priorities Most widely used templates Top 200 From 200 to 1000 Template watchlist Infobox accessibility
Guidelines for MediaWiki Introduction for developers MediaWiki specification
Coordination Manual of Style draft Methodology Resources and references Policy proposal
Help for impaired users Using JAWS Keyboard shortcuts Style sheets

WebAIM Survey of Preferences of Screen Readers Users

A preliminary summary of results from WebAIM's Survey of Preferences of Screen Readers Users has been published. —Michael Z. 2009-02-02 05:13 z

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)

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}} → ½
• {{fraction|1|3}} → ⅓
• {{fraction|1|4}} → ¼
• {{fraction|3|4}} → ¾
• {{fraction|1|5}} → ⅕
• {{fraction|1|6}} → ⅙
• {{fraction|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}} → ⅕
• {{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}} → ¹⁄₂
• {{frac|1|7}} → ¹⁄₇
• {{frac|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".

³⁄₄ 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)

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)

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)

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)

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 [1]). 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 Bugzilla
Bug 41694

Tracked in Bugzilla
Bug 41695

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)

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)

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)

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)