Showing posts with label Accessibility. Show all posts
Showing posts with label Accessibility. Show all posts

Wednesday, June 04, 2014

Lila, a personal request

What would you do when you find that Wil, your partner, finds the experience of reading a Wikipedia article much enhanced by a MediaWiki feature that is really well hidden. Somewhere, there is this option that makes the Wikipedia experience much easier for people with dyslexia. Do you know it exists? Could you find and enable it for him? Please do try and find it..

Yesterday we had friends for dinner. We got to talk and I found that one of them was helped with this feature. Interestingly enough he does not suffer from dyslexia. We talked about perception of text and my wife mentioned that she has to read one letter at a time to make up a word. For her this feature proved to work as well, she found that she could now recognise some words at a glance..

The feature is hidden really well. So much so that I have to search for it every time. I know it exists, I have written about it before. It is "only" 7 to 10% of a population that is dyslexic. The Wikimedia Foundation wants more readers, editors. I really wonder how much effort it takes to make this feature sufficiently prominent. It does not cost any development; the software exists. All it takes is the realisation that we can open up to so many more people.
Thanks,
     GerardM

Monday, June 04, 2012

#wmdevdays - #accessibility

At the Berlin #hackathon 2012 many people were hacking on many subjects. Kai Nissen worked on the accessibility of MediaWiki by people with a visual impairment. At the end of the hackathon several bugs were squashed and ready for review in Gerrit.

It is wonderful when reports on defects are actionable and when something gets done.
Thanks,
     GerardM

How was the Berlin Hackathon 2012 for you
I participated in the Hackathon for the very first time and was quite amazed about so many people coming together and actually work productively on feature enhancements or bug fixes. I had a lot of talks with people who gave really helpful feedback about the project I'm currently working on.

You have been working on accessibility for the blind ... how did you get into this subject
I was pointed to an analysis report concerning accessibility in Wikipedia that was carried out by the Swiss initiative "Access for all". While reading this I realized that a lot of the mentioned issues were
quite easy to solve. A lot of the content available on the web seems to be designed without considering accessibility aspects, although a little tweak can always have a high impact.

How do you know what to focus on
The analysis report was quite thorough and included recommendations, so it ended up to be something like a task list.

You identified a number of issues to work on this weekend .. how did it go
The issues I was working on were quite easy to fix, whenever I had problems with something there was always somebody around to help out.

Did having all these other hackers make a difference ?
The gathering of all those experienced MediaWiki developers is a really helpful thing. That applies to having certain questions answered rightaway as well as just sharing experience in whatever topic might
come up.

Brion Vibber helped you with the parser tests ...
Brion figured out what the problems was in no time. There has been a language version related bug in another patch which he simply reverted.

Are there many more accessibility issues in MediaWiki people can help with
The accessibility analysis report mentions more issues that need to be fixed to make Wikipedia and all other projects based on MediaWiki more accessible. It is clearly written and points out lacks of accessibility very

How do you continually test for good accessibility of our software
Most of the time one seldomly notices lacks of accessibility when not being affected by disabilities. Whatever issue I fixed for improving accessibility I have to keep in mind to apply that again in a similar case.

Are there best practices for coding for accessibility
There are guidelines defined by the WAI, which should be considered when coding for accessibility.

Do you have thoughts on what the Visual Editor will do for accessibility ?
Since screen readers will read what is written on the screen it also reads the wikitext as is. That might be hard to understand, especially for newcomers. Reading out a headline as a headline instead of
"equals-equals-headline-equals-equals" can be very helpful to focus on the subject itself.
 --- Kai

Tuesday, August 30, 2011

#MediaWiki is used by the visually impaired

#Wikipedia edited by the blind? How do they do it and, particularly what tools do they use?

The first thing that comes to mind is the use of systems based on Braille. Braille was originally developed for the Latin script but there are implementations for other scripts.

There are Braille implementations for Indic scripts, they are using a common system called Bharati Braille. A transliteration where Roman letters with specific diacritic marks i.e., symbols written above or below a letter, is used to write text in Indian languages. This Roman transliteration had been in use for many years and the idea behind Bharati Braille is to use 63 cells as a special script to represent text uniformly in all the Indian languages.

Bharati Braille Reference : Oriya

Braille systems for computers are expensive so there is a need for alternative technologies. Enter eSpeak, a compact open source software speech synthesizer that works for many languages including Hindi, Kannada, Malayalam and Tamil.

The quality of the system varies per language; there is often a lot more that can be done to improve the quality and make it more understandable. It does however provide a tool that works and is freely available as it is open source.

The video below is a presentation that explains how eSpeak is used to edit the Malayalam Wikipedia.



Spreading awareness of tools like eSpeak is important as it enables people to use computers, it opens the Internet to them and as you can see it allows them to use MediaWiki to the fullest.
Thanks,
      GerardM

Tuesday, May 31, 2011

Why language identification

The #W3C updated their document "Why use the language attribute?" If there is ever a better explanation why there will be a WebFonts release 0.5 you find it in this article.
Applications exist that can use natural language information about content to deliver to users the most relevant information based on their language preferences. The more content is tagged and tagged correctly, the more useful and pervasive such applications will become.

Language declarations specify the 'natural language' of web page content. A declaration should always be used to indicate the language of a web page as a whole. If the language changes within the main page container element this should also be reflected in a sub-container element, eg. span, div, td, p, etc.

Information that indicates content language can be useful for many applications. Some of these work at the level of the document as a whole, some work on appropriately labelled document fragments. What follows is a list of a few possible applications for language information:
Please read the articles for the applications.. of those applications, the one on accessibility has quite profound implications for achieving our goal:
Language information assists speech synthesizers and Braille translators; it is required by the W3C Web Accessibility Initiative (WAI) and enforced by governmental policies in some countries, eg. UK - Disability Discrimination Act (UK).
Thanks,
       GerardM

Monday, April 18, 2011

The roar for #Wikipedia in #India

Three Blind Mice
Charles Folkard 1927
When you are #blind, you can not read Wikipedia. You may have a #Braille terminal but when you don't you are out of luck. To be honest, I do not even know if that works for Indic languages.

The best we can do is have Wikipedia articles read to you. However, when people are to record articles, it means a lot of effort that gets you readings that do not get updated.

Ideally we would give you a TTS or Talk To Speech application. Funnily enough this is something we can give you on-line only for the Indic languages thanks to the Silpa TTS application called Dhvani.

It works for Gujurati, Hindi, Odiya among many others and it could be made into a MediaWiki extension.
Thanks,
        GerardM

Sunday, March 13, 2011

The power of nice

A reader of the #Malayalam #Wikipedia, a visually impaired reader at that, send a thank you e-mail to Santhosh because he could follow the text thanks to the Dhvani text to speech application. 

Dhvani is capable of producing intelligible text for 11 Indian languages.
  • Bengali
  • Gujarati
  • Hindi
  • Kannada
  • Malayalam
  • Marathi
  • Oriya
  • Panjabi
  • Tamil
  • Telugu
  • Pashto (experimental)
All these languages have their Wikipedia and it is a happy surprise that a solution for accessibility issues for these Indian languages is a reality.  The Wikipedia reader was grateful for what he had and asked if it would be possible to have  Dhvani express input from the keyboard so that they are helped from "login" to "logout".

As the Silpa project has applied for this years Google Summer of Code, when Silpa is selected that could make this a reality this year.
Thanks,
       GerardM

Sunday, December 14, 2008

Web Content Accessibility Guidelines

The W3C has published its Web Content Accessibility Guidelines (WCAG) 2.0. These recommendations have been worked on to make the Internet more accessible for people with disabilities and for older people and it aims to increase the usability of websites across a variety of mobile devices.

This improved standard addresses the barriers to accessing the Web experienced by people with visual, auditory, physical, cognitive and neurological disabilities, and by older Web users with accessibility needs. WCAG 2.0 explains how to make content:
  • Perceivable (for instance by addressing text alternatives for images, captions for audio, adaptability of presentation, and color contrast);
  • Operable (by addressing keyboard access, color contrast, timing of input, seizure avoidance, and navigability);
  • Understandable (by addressing readability, predictability, and input assistance); and
  • Robust (for instance by addressing compatibility with assistive technologies).
The publication of this standard comes at a time when the Wikimedia Foundation is preparing its Stanton project team to address usability. Even with $890.000,-- there is only so much that you can do and the research by UNICEF has made it painfully clear how much work needs to be done on MediaWiki usability. Browsing the text of this improved standard, it is clear to me that this standard is written to a large extend for the classic websites that are quite static in nature. The content of wikis are generated by its communities and consequently it will be hard to make it available in all the different ways discussed in these guidelines. I do expect that there is much in there that is relevant.

The Stanton team will start its work in January with assessing what has already been done by others on usability. In the WCAG 2.0 it finds guidelines that help our projects to become accessible for people with disabilities. It is a happy coincidence that these standard have been published before this work actually started.
Thanks,
      GerardM