Accessibility Plans for Launchpad

Asked by matatk on 2007-11-09

As you are probably aware, ``accessibility'' is a measure of how possible it is for people with disabilities to receive the information presented by, in this case, a web site.

I started using Launchpad because it provides exactly what my project needs and is also accessible (CSS for layout, tables only when necessary, simple layout and navigation). It seems that the Code of Conduct would impart the attitude that (as with Ubuntu) we should try to afford access for as many people as we can. Launchpad already goes a long way towards this, in my opinion and that of the other developer of our project (AGRIP), who happens to be totally blind.

The purpose of this question is to find out if there is a part of the development team of Launchpad responsible for ensuring that Launchpad remains as accessible as it is now, or even improves in this area. Is there such a team? If not, could we, the users, be involved in discussions on how to maintain and even improve accessibility?

One suggestion I have is providing skip links and access keys to allow skipping of navigational elements, so that blind users can easily get to the main content of the page without their screen readers having to read out all of the menus. As I said, the service is already very good on this front, but I do feel that implementing this feature would make things rock maximally.

So, the question is, again: ``What measures are being taken to ensure and promote accessibility in Launchpad and how can we, the users help?''

Question information

English Edit question
Launchpad itself Edit question
No assignee Edit question
Solved by:
Matthew Paul Thomas
Last query:
Last reply:
Luke Faraone (lfaraone) said : #1

You, the user, can file a blueprint.
Blueprints are the way that progress is made in launchpad.

File a blueprint, and file bugs and link them to the blueprint.

matatk (matatk) said : #2

Thanks for your answer; we will work on at least one blueprint for this issue.

I was also trying to determine if the relatively high level of accessibility of Launchpad has been arrived at simply because you wanted to follow standards and best practices, or if you do actually have a specific group of people who are in charge of ensuring accessibility. Whatever the process, it seems to be successful and, as it's one of my areas of research, I'd really appreciate knowing how the project achieved this.

Thanks for your continued time!

Best Matthew Paul Thomas (mpt) said : #3

Hello Matthew,

Part of my job is ensuring Launchpad's accessibility. Mostly our efforts have been hopeful -- doing things because we trusted they would help, rather than because we could see the effects directly (though at least one of our team has colorblindness). Two weeks ago, however, I conducted usability testing of Launchpad including one subject who was nearly blind, and it was good to observe him having very little trouble using Launchpad with elinks and a screenreader. It's gratifying to read that your colleague is similarly able to use Launchpad, so thank you for passing on those comments.

To some extent our accessibility comes from just using HTML properly: keeping pages valid (or nearly valid) so they work in a wide variety of UAs, using "unobtrusive JavaScript" for the same reason, using CSS rather than tables for layout, using semantic elements (such as <h2>) where appropriate, and choosing alt= text that's the most appropriate text equivalent (which often means alt=""). But there are a couple of things we've done specifically for accessibility:
* ensuring that all uses of color are either decorative (e.g. headings), redundant with text (e.g. bug importances), or tested on colorblind people (e.g. translation status charts);
* using CSS trickery so that less-important information that's visually on the left comes after more-important information that's visually on the right.

There are a few areas where I'd like to improve Launchpad's accessibility:
* simplifying the headings and navigation at the beginning of each page (to help anyone using a non-graphical browser);
* moving the action links to more relevant places within the page content (to save time for everyone, but especially those using non-graphical browsers);
* respecting preferred font size (to help people with partial sight);
* making the layout more robust when text is zoomed in and out (ditto);
* removing the hidden sort keys that are present in some of our tables (to help anyone using a browser that doesn't do CSS).

I plan to work on most of these during the next few months. I'm confident that the first two in particular will make skip-links unnecessary (screenreader users will be able to just jump to the <h1> instead). And I'm not keen on using accesskey=, because from my research it seems more harmful than helpful.

If you find any specific accessibility problems, please report them as bugs. ffm is not quite correct that you should use blueprints; they're more for the Launchpad team's own use in planning new features.

Hi Matthew (of Launchpad ... :-) ),

Due to the inevitable failure of my hard disk on my Windows box, the other browser I use - Internet Explorer with Windows GUI screen reader - isn't available. So, I too am using Elinks right now (configured to lie and pretend IE, of course :-( ) with brltty as screen reader for the braille terminal. Braille slows me down compared to speech, but it's all I have and this server box is my most reliable.

Launchpad is really very good with textmode browsing, as you say (there is one small issue due to Elinks caused by the fact that post-login redirects send you to pages that are already cached, so Elinks must be forcibly refreshed to get the new privileges for a given page once you use the Log In link).

Anyway, the important thing was Skip Links and their lack. I agree headings are nicer, but for one problem: they're only faster to use for screen reader users if the screen reader itself provides the feature. Skiplinks are redundant if made invisible for use only by screen readers if headings are available, because there's a hotkey specifically for jumping the buffer focus to the nearest next heading. In that case they are very fast; hit a key and be ready to read without a buffer reload required after clicking an anchor. But with textmode browsing, it's quite different - the users will have to manually search for the point where navlinks end and content starts. So long as you don't have more than, say, half a screen (12 lines - I never 'cheat' and won't run my display at more than 80x25) of navlinks this probably isn't such a big deal, but if you do it might be nice to put a visible skiplink in to get the user's textmode browser's top line to coincide with the top of the content at an anchor put there. That's assuming it doesn't uglify what you already have, of course. The link would have to be actually visible though, since here textmode browsing isn't like the robotic browsing of screen readers.

Anyway, you lot are doing an excellent (pleasantly
surprisingly!) job with accessibility of this site, and as you can see things are working very well for me so far. Now, if we could just have like-minded consideration in the development of other sites as well ...

Thanks, and keep it up!


Matthew Paul Thomas (mpt) said : #5

Sabahattin, currently a typical Launchpad page in elinks has between 11 and 14 lines (not counting blank lines) of hierarchy, login details, object heading, search form, and applications links, before the interesting stuff begins. As a side-effect of other design changes I'm doing, I intend to reduce this initial overhead to 3 lines. So in a text browser most of the first screenful will be interesting stuff, just as it is currently in a graphical browser.

matatk (matatk) said : #6

Wow! Thanks, mpt, for your very comprehensive and reassuring response. I have to say I was already impressed with the fact that you've decoupled the visual layout from the HTML layout, keeping the action links away from the top of the page. It sounds like a lot more very useful improvements are planned for the next few months, so it's probably a good idea for us not to report a but about skip links now, as it sounds like they may not even be necessary in the future.

I'd like to echo sgucukoglu's appreciation for what you're doing. This conversation has really enabled me to feel good about the move to Launchpad (most of our users are blind).

Thanks for the great service and accessibility work!

matatk (matatk) said : #7

Thanks Matthew Paul Thomas, that solved my question.