MarkUs Blog

MarkUs Developers Blog About Their Project

Accessibility in MarkUs

with 6 comments

I have been working on making MarkUs more accessible, particularly to blind users.  To help me with this goal I installed a free open source screen reader, NVDA.  I plan on using other screen readers and technology in the future as well as working with blind users.

To begin with, the screen reader is really fun, but after navigating for sometime you start to get frustrated with the length of time that it takes to do some things, and the voice gets annoying too.  I can see why people who use screen readers all the time make the voice go so fast, you want to be able to listen to everything as fast as you could read it visually.

After working with MarkUs for a few days in this format, here are some key features for accessibility that I need to work on, and which other developers should keep in mind when working on user interfaces:

  • Everything has to be accessible using the keyboard only!  This is the only input method that we can assume everyone will be able to use.  The biggest problem with this in MarkUs is the accordion menus, they are only accessible through the mouse.  We will have to either get rid of them or make it so that they can be navigated to using the keyboard.  Another problem is dragging and dropping for reordering things, this is really convenient with the mouse and should not be removed, but we should add alternative buttons for keyboard access.
  • Focus is a problem, especially with javascript making new boxes and windows appear.  When these things appear the focus remains where it was before, and when you are using only a screen reader it seems like nothing happened.  For things like the upload file window, the box that seems to be in front of everything else on the screen is actually at the end of the document, so you have to tab through a lot of things until you see that something new has actually appeared.  If we could automatically change the focus when something like this appears, that would be a lot of help, and it would probably help everyone else too.
  • Every form input element should have a label!  We are pretty good at doing this so far, but there are places here and there where there is text that describes the form element, but is not formatted as a label.  It’s pretty easy to change this text into a label and it really helps to identify what each element does, otherwise you just hear something like “checkbox unchecked” and have to go hunt for the text that labels it.  There are some places where having a label does not make sense for sighted users (like in a table of students, we don’t want to have a label beside each checkbox) but we can make hidden labels in this case for the benefit of people who don’t see the visual association.

Overall we have already done a good job of making things accessible just by following web conventions well, and if we deal with the points I mentioned above then I think MarkUs will be doing well  accessibility-wise.  The next step is to work with someone who actually requires the use of a screen reader, and I’m sure I will learn a lot more about what we could do to make things better!

I am using the wiki page as a way to keep track of progress for myself, look there for more specific details.

Written by Evan

June 1st, 2010 at 9:57 am

Posted in Uncategorized

6 Responses to 'Accessibility in MarkUs'

Subscribe to comments with RSS or TrackBack to 'Accessibility in MarkUs'.

  1. Hi,

    Nice post here ! Making Markus accessible is going to be a challenge… Here are a few information that might help you:
    – the most widely used screenreader is jaws: http://www.freedomscientific.com/products/fs/jaws-product-page.asp it only exists for windows, and is nor opensource, nor free, but I am sure you can manage to have a version.
    – W3C has loads of documentations on accessibility, which probably can help you.
    – things which are not displayed on the screen are not read: ie, if you have a display: none in the code, it will not be read. Basically, it is not because the html code is rendered, that is will be read by the screen reader.
    – Everything indeed should be accessible throught the keyboard, but everything should also respect the standards (that is is the most important thing when working with blind people). Implementing a shortcut that “overrides” a default one is no good.
    – Everything that used javascript for display purpose is horrible for accessibility: not only accordion, but ajax, and feedback display.
    – Users are usually the source of many accessibility problems: a forum is almost never accessible to blind people because of other users writing none valid stuff.

    And last but not least, a blind person will not use a screen reader the way you do. They navigate increadibly fast into webpages.

    Nelle

    1 Jun 10 at 11:12 am

  2. Thanks for the comments! I have spoken to a contact at the university about using JAWS for testing, but I will wait until I have fixed the obvious problems first because I can’t install it on my own computer.

    I think W3C compliance is very important too and Benjamin agrees 😉

    I had heard that nothing that is not displayed will be read, but my accessibility book recommends having hidden labels in some cases, so I am not sure whether that is an exception or something… A label is read when the associated form element is selected, so maybe as long as that element is visible it is ok.

    About the javascript, do you think it is worth it to try to get the site working without it? It seems like it would take a lot of work, but it would definitely be more accessible then. I would like the opinion of those of you who have done a lot of work on MarkUs as to whether or not this is a feasible thing.

    Evan

    1 Jun 10 at 11:35 am

  3. We are already planning to get rid of the accordion menus. They don’t work very well even with the mouse.

    Karen

    1 Jun 10 at 2:03 pm

  4. I’d just like to echo Nelle’s comment. Not only is JAWS one of the most widely used screen readers out there right now, but a lot of large corporations use it to ensure the accessibility of commercial software as well. I’ve recently done a few assessments using JAWS, so just let me know if you need help — although I’m not quite an expert at it yet. 🙂

    Just another thing to think about — Windows has this accessibility feature where the user can turn the display into High Contrast mode. It’s designed to assist visually impaired individuals to view the computer screen (and the information presented on it) easier. I’ve only seen it work with OS based applications, but I suppose the concept would be interesting to look into if we’d really like to make MarkUs accessible in ways that go beyond just screen readers and keyboard interaction in the future.

    Victoria

    2 Jun 10 at 9:57 am

  5. To answer my own question from above, from looking at the code it seems that it would be an enormous amount of work to make MarkUs work without javascript… probably not worth it despite the accessibility issues.

    Evan

    2 Jun 10 at 2:31 pm

  6. RE: Implement MarkUs in non-JavaScript-ways:

    I my opinion the best way to go about this would be to keep the fully featured AJAX-ified interface for regular users, but make sure that content is at least readable on JavaScript disabled browsers. Text-only (console) browsers such as w3m and lynx on Linux are helpful. Work is required on the grader view. Not everything is displayed. Basically we need to add some hook to get to code annotations. Once that is done we are already a big step further down the accessibility road.

    In short, a usable read-only MarkUs for non-JavaScript capable or disabled browsers would be already a huge win 🙂

    Just my 2 cents worth.

    Severin

    2 Jun 10 at 11:43 pm

Leave a Reply