Hi. I need your help. I would like to search for sponsors for a project which shall increase the accessibility and usability of the Mediawiki user interface for blind screen reader users. I collected my first thoughts at http://blind.wikia.com/wiki/Accessibility_and_Wikis
I would be glad if some of you could post comments, suggestions or useful links to the talk page.
For example: I would like to learn why it is not possible to use the Mediawiki extension from reCAPTCHA for Wikipedia. This would allow the use of an alternative audio CAPTCHA, but there are surely important arguments against this idea.
Don't worry, I am not an accessibility hawk. I just want to inform about the needs of blind Wiki users.
There should be lots of potential sponsors for the suggested accessibility/usability development project. If one or more parties would give money, a professional Wiki programmer could be hired to optimize the monobook CSS and JS for screen reader software. After that, the results and experiences could be used for a screen reader skin or gadget for the MediaWiki software. Organisations and companies such as the Mozilla Foundation, the GNOME Foundation, Sun Microsystems, IBM, Canonical, Novell, Google and many other parties already support open source accessibility projects.
Why shouldn't we find similar help for MediaWiki and thereby for the great and well known Wikipedia? The costs would be low and the benefits significant. The WikiMedia Foundation and the global blind community will surely appreciate sponsored accessibility improvements.
I would like to search for sponsorship opportunities for such an development project. I don't want the Wikimedia Foundation to pay for anything, but I need interest and supporting words from Mediawiki experts first. Accessibility improvements for blind users could be used as another argument for the PR of Wikimedia Foundation and thereby for future fundraisings. What do you think?
Best regards from Germany, Per
On 10/04/2008, Per Reisender@online.de wrote:
For example: I would like to learn why it is not possible to use the Mediawiki extension from reCAPTCHA for Wikipedia. This would allow the use of an alternative audio CAPTCHA, but there are surely important arguments against this idea.
I believe the answer is that reCAPTCHA is not even close to free software, and they don't seem interested in freeing it.
There was talk here a short while ago of putting stuff in the MediaWiki bot API to make bolt-on captchas of any sort (text, audio, whatever) much easier to implement.
Don't worry, I am not an accessibility hawk. I just want to inform about the needs of blind Wiki users. There should be lots of potential sponsors for the suggested accessibility/usability development project. If one or more parties would give money, a professional Wiki programmer could be hired to optimize the monobook CSS and JS for screen reader software.
An easier way is to use a skin suited to screen reading. Classic, Nostalgia or (especially) the printing CSS would be much better suited to screen reading than Monobook, whose purpose is, after all, to look slick and pretty.
Why shouldn't we find similar help for MediaWiki and thereby for the great and well known Wikipedia? The costs would be low and the benefits significant. The WikiMedia Foundation and the global blind community will surely appreciate sponsored accessibility improvements.
Mostly I suspect it's a case of "Great idea! Please code it." Sponsorship could help here, of course.
- d.
David Gerard schreef:
I believe the answer is that reCAPTCHA is not even close to free software, and they don't seem interested in freeing it.
There was talk here a short while ago of putting stuff in the MediaWiki bot API to make bolt-on captchas of any sort (text, audio, whatever) much easier to implement.
That's happened. The action=edit API module supports all types of CAPTCHAs, as long as they provide a URL to a file (which can be an image, audio, or whatever) and the file's MIME type. Text-based CAPTCHAs are also possible (text can be passed inline as well, rather than through a URL), but probably not very useful in real-world cases.
Roan Kattouw (Catrope)
David Gerard wrote:
An easier way is to use a skin suited to screen reading. Classic, Nostalgia or (especially) the printing CSS would be much better suited to screen reading than Monobook, whose purpose is, after all, to look slick and pretty.
This is mostly untrue, while Monobook does look nice, it has the side-effect of gracefully degrading. Several times I have used Monobook in text-based browsers (which, while I know is not a screen reader, gives a good impression of how the page would "render" in a screen reader) it works very well with the content laid out in a suitable way. Many of the older skins are definitely not very accessible as they were developed before accessibility became a hot topic and some even use tables. The print stylesheet is also mostly useless since screen readers generally do not use CSS and the printable version is simply a version of the page with navigation, tabs etc. (which appear at the bottom of the page in screen readers anyway) hidden (they are still within the HTML, just invisible to the user).
MinuteElectron.
On Thu, Apr 10, 2008 at 5:13 AM, Per Reisender@online.de wrote:
For example: I would like to learn why it is not possible to use the Mediawiki extension from reCAPTCHA for Wikipedia. This would allow the use of an alternative audio CAPTCHA, but there are surely important arguments against this idea.
Not only is reCAPTCHA closed-source, it also adds a dependency on third-party servers. If their servers go down -- they might not be prepared for the load of a site like Wikipedia -- people presumably won't be able to log in, without expensive and unreliable uptime checks on our part. It adds another point of failure.
Plus it's closed-source, again, which makes it unacceptable by itself.
I would like to search for sponsorship opportunities for such an development project. I don't want the Wikimedia Foundation to pay for anything, but I need interest and supporting words from Mediawiki experts first.
The answer is that if you can find us someone who can improve MediaWiki's accessibility, and who knows what they're doing and is willing to follow our coding standards, etc., it should be no problem to give them commit access. We have at least one person already (Greg Sabino Mullane) who more or less does nothing but maintain a single facet of the software that no one else cares to maintain (PostgreSQL), and has commit access AFAIK solely for that reason.
On 10/04/2008, Simetrical Simetrical+wikilist@gmail.com wrote:
On Thu, Apr 10, 2008 at 5:13 AM, Per Reisender@online.de wrote:
For example: I would like to learn why it is not possible to use the Mediawiki extension from reCAPTCHA for Wikipedia. This would allow the use of an alternative audio CAPTCHA, but there are surely important arguments against this idea.
Not only is reCAPTCHA closed-source, it also adds a dependency on third-party servers. If their servers go down -- they might not be prepared for the load of a site like Wikipedia -- people presumably won't be able to log in, without expensive and unreliable uptime checks on our part. It adds another point of failure.
If reCAPTCHA were free software - or if someone duplicated its functionality in free software - and it were running on a Wikimedia server, would it (or something like it) be something we'd likely run? Given its usefulness to the world of getting public domain stuff from image to text form.
- d.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Gerard wrote:
If reCAPTCHA were free software - or if someone duplicated its functionality in free software - and it were running on a Wikimedia server, would it (or something like it) be something we'd likely run? Given its usefulness to the world of getting public domain stuff from image to text form.
If you mean their general project of using text image captchas to do spell-checking of scanned documents, I'm not sure we'd bother. :)
If you mean specifically their alternate audio captcha mode, then sure... but that's not anything really specific to do with reCAPTCHA. The only thing stopping us from having an audio captcha is that nobody's put the work into implementing it yet.
- -- brion vibber (brion @ wikimedia.org)
On 10/04/2008, Brion Vibber brion@wikimedia.org wrote:
David Gerard wrote:
If reCAPTCHA were free software - or if someone duplicated its functionality in free software - and it were running on a Wikimedia server, would it (or something like it) be something we'd likely run? Given its usefulness to the world of getting public domain stuff from image to text form.
If you mean their general project of using text image captchas to do spell-checking of scanned documents, I'm not sure we'd bother. :)
Yeah, that's what I was thinking of. I'm wondering if there'd be anything in that for us. Do the Wikisources ever do transcription projects?
- d.
On Thu, Apr 10, 2008 at 5:25 PM, David Gerard dgerard@gmail.com wrote:
Yeah, that's what I was thinking of. I'm wondering if there'd be anything in that for us. Do the Wikisources ever do transcription projects?
Catching vandal edits might be doable, but I dunno if we want people to have to see "PENIS PENIS" when they log in... :)
David Gerard wrote:
On 10/04/2008, Simetrical wrote:
Not only is reCAPTCHA closed-source, it also adds a dependency on third-party servers. If their servers go down -- they might not be prepared for the load of a site like Wikipedia -- people presumably won't be able to log in, without expensive and unreliable uptime checks on our part. It adds another point of failure.
If reCAPTCHA were free software - or if someone duplicated its functionality in free software - and it were running on a Wikimedia server, would it (or something like it) be something we'd likely run? Given its usefulness to the world of getting public domain stuff from image to text form.
- d.
Probably. But the third party dependency can be avoided if we just provide their Audio captcha as an alternative to our FancyCaptcha. The number of queries to handle would be much lower, and if they went down, we would be exactly as now. However, they may not like being used for audio without filling in the text ones.
From: "Platonides" Platonides@gmail.com
On 10/04/2008, Simetrical wrote:
Not only is reCAPTCHA closed-source, it also adds a dependency on third-party servers. If their servers go down -- they might not be prepared for the load of a site like Wikipedia -- people presumably won't be able to log in, without expensive and unreliable uptime checks on our part. It adds another point of failure.
Probably. But the third party dependency can be avoided if we just provide their Audio captcha as an alternative to our FancyCaptcha. The number of queries to handle would be much lower, and if they went down, we would be exactly as now. However, they may not like being used for audio without filling in the text ones.
This sounds interesting because I am only interested in an audio CAPTCHA but not in reCAPTCHA's visual verification solution. Is it imaginable just to use their audio feature for Mediawiki/Wikipedia if they would provide it? If the answer is yes I will contact them, find out more and could try to convince.
wikitech-l@lists.wikimedia.org