dw_accessibility | Recent Entries

There are a few accessibility improvement in last night's code push, detailed here for your viewing pleasure:

The form to submit a support request now has labels so it can be reasonably navigated with a screenreader.
The UI used by support volunteers now has improved visual indicators so that it doesn't rely on colors to relay information.
The cut tag arrows are now higher resolution and scale properly for people using larger font sizes.

There are also two accessibility *ahem* bugs introduced in last night's code push: the new cut tag arrows don't have a white outline so they are difficult or impossible to see on dark backgrounds, and a fix to the contextual userhead hover to fix coloration in certain styles causes viewing problems in certain other styles. Fixes for both of these will be pushed ASAP.

deborah

Dreamwidth makes its dropdown menus accessible without a mouse by making the top-level items links to lists of the menu items on a new page. There's been a lot of work lately to make complex dropdowns accessible without page reloading. I'm curious what kinds of dropdown menus are accessible to you, our users, whether your disabilities are mobility, visual, cognitive, or something else.

This poll lists the current system as it stands, as well as links to 15 alternative, keyboard-accessible menus (all but the first two are non-real-world examples from Terrill Thompson's awesome resource). I would love if all y'all could test and see which options have reasonable usability for you, no matter what functionality you use to manipulate and view it.

And if you don't know if you should take this poll? If you think you have accessibility needs in any way, please do! I know it's time consuming but I'll love you forever.

Poll #13618 Accessible dropdowns

Open to: All, detailed results viewable to: All, participants: 6

View Respondents

Which menus are functional for you?

View Answers

The current system
4 (66.7%)

University if Washington
2 (33.3%)

Adobe (described here)
3 (50.0%)

Interesting Example 1
3 (50.0%)

XHTML Strict
4 (66.7%)

HTML5
4 (66.7%)

Suckerfish
3 (50.0%)

Son of Suckerfish
3 (50.0%)

Superfish
2 (33.3%)

Dropper Dropdown Menu
3 (50.0%)

UDM4
5 (83.3%)

Simply Accessible
4 (66.7%)

YUI
4 (66.7%)

Customized OAA Dropdown
4 (66.7%)

JQuery-ui Menubar Widget
3 (50.0%)

Canadian Government Web Accessibility Toolkit
0 (0.0%)

deborah

I was process of fixing an inaccessible form, and went to go swipe some CSS from another form -- and realized that other one also had accessibility problems. Whoops.

So now I'm on a mad dash to do some form accessibility remediation. It's a nice easy task which provides a big net win.

Tell me which forms you have accessibility problems with, and I will add them to my list.

The ones on my current list are the poll creator and the form to submit a support request.

At a minimum, tell me which form causes the problems, and I will play with it. Ideally, tell me

which form causes the problems
the nature of the problems
what browser and browser version you are using
what adaptive tech you are using, if any

foxfirefey

How can you program if you're blind -- a question on StackOverflow that gets some thorough answers from blind programmers. Figured it might be interesting reading for others who, like me, are interested in the tools and processes.

jeshyr

[OK I have been meaning to post this for about a month and I keep putting it off on account of not having the right phrasing, but hey ... wrong phrasing will have to do]

My basic question is to those developers/volunteers/users of Dreamwidth who are NOT themselves users of accessibility technology...

I know that a bunch of folks here have become accessibility converts/evangelists. By which I mean that you're not just "doing accessibility" because Dreamwidth requires you to, but you're really understanding why it's necessary and important and often you're pointing this out to others in other contexts away from Dreamwidth too.

I know that a project can require people to "do" accessibility, but a project can't make people *care* about accessibility... and most projects that "do" accessibility at all are in the first category. So ... how did you come to care about accessibility, especially if Dreamwidth was involved??

I have been chatting to Liz Ellcessor who is writing a book about web accessibility specifically and wants to know about Dreamwidth's accessibility from the inside, but it's also just a thing I have been wondering about more generally too. Dreamwidth is known for "doing accessibility" well and part of that is that we have got a bunch of people fired up about it and that's a really hard thing to do!!

So how do you think you caught accessibility?

deborah

How do keyboard users feel about the Navigation Strip at the top of reading pages? (The one that, when you're logged in, shows your tiny default userpic and links for Home, Post, Reading, Settings, Inbox. In Bug 3302, there's a request to move the navstrip later in the tab order, so it's not the first thing you interact with, since you so rarely want to interact with those options. But is that true? Is it convenient, inconvenient, or neutral that when you first start tabbing around the page you go to the navstrip first?

deborah

just an FYI: the "insert image" pop-up on the HTML version of the post-creation page now has the option to add alternative text, and both the HTML and Rich Text Editor versions of the "insert image" pop-up now link to a (soon to be improved) FAQ explaining what this wacky "short description" field is for. So if you know people who are putting images into their posts without alternative text, you can explain to them how incredibly easy it now is to add alt text.

Of course it now occurs to me that if I really want to make a difference in people's Internet experience, I should go contribute an easy way to add alt text to the tumblr code base.

Somebody, go do that!

denise

Gimme your favorite web accessibility discussion blogs, sites, resources, etc!

denise

I'm doing a talk on web accessibility at LinuxConf Australia and would like to give specific examples!

So, gimme your best examples of websites with specific accessibility problems that drive you nuts. Use of tabular data where it doesn't make any sense, sites with horrible contrast or that won't let you change font sizes, restaurant websites that are entirely flash-based, etc, etc.

Also, if anybody knows of good illustrative videos of a) people listening to a screenreader and b) people dictating to their computer, point me at 'em?

autisticalice

I think there should be a banner or something saying if maintenance will be at a certain time and to prepare for it. I came up with this idea because of the recent maintenance where it was rather unpredictable and I had no idea it was coming. As a disabled person, I need to have predictability in order to plan my activities wisely so that nothing bad is triggered.

Otherwise, unpredictability might trigger a big meltdown. I'm sure there are other users that don't have twitter or ways of knowing when maintenance will happen since they might not check the dw_maintenance constantly to check. What would be effecient is having an estimate of the time for maintenance before it starts, how long it will be and whatever.

As I said before, I'm the type of person that needs predictability and proper structure so that a meltdown/outburst isn't triggered by a surprise maintenance closure, especially when I don't know how long that will last, it can cause a lot of distress for me.

I don't think there would be any drawbacks, except maybe it might bother some people but it is more beneficial to be aware of what is going to happen. it will give people time to plan what they want to say wisely and possibly know that they have to make an entry before the maintenance starts... or whatever.

(I'm not sure if this is allowed but it is a real problem for me)

Current Mood: anxious

denise

Over in

dw_suggestions I am floating the first tentative questions about a redesign of the inline commenting form (the one that comes up when you're reading an entry and pick "leave a comment", not the one that you get from the "more options" link or if you load a link with ?replyto=foo on it) and asking people for opinions on whether the "check spelling on preview" tickybox needs to remain in the inline-quick-reply form. If you've got access needs around that workflow, please chime in over there, or at least ticky the "no" option in the poll!

deborah

As of tonight's code push, entry and reading pages have headers while read in site scheme (example), for better screenreader and other navigation.

Also, as

denise mentioned in tonight's news post, we are aware that the new photo hosting doesn't yet have alt text but that is a top priority fix. This is a beta launch, and alt text will come Real Soon Now.

dunvi

I was poking at bug 4385, which hopes to add an option for scaled down images in the shiny new icon browser. What I found when I was playing around was that when the images are scaled (down to 50% width and height, so a quarter of the original size), the meta text feels very squished, and there's a high chance of your keywords or descriptions ~~stretching things around nuttily.~~ [ETA: that comment was based on an example mid-debug - the working version doesn't stretch around, but things get cut off if you have more than about one keyword and two words of description text.] Furthermore, I personally found that mini pictures with meta wasn't any more useful (in fact slightly less so) than just using the drop down selector in the first place, but I wanted to check with wiser people, (especially people with more than just a few icons, or who may be using the site differently than me).

How do people feel about perhaps leaving the option for meta info with scaled images out entirely? What I mean is that, instead of two toggles, one 3-way toggle with options of half sized images, full sized images, and full sized images with meta info.

( images below the cut )

deborah

I'd like to find out how many people would like it if we had skip links, which are essentially links which are the first content on the page, which allows someone (usually someone using a screenreader, keyboard navigation, or magnification) to go directly to the main content on the page.

Poll #10458 Skip Links

Open to: All, detailed results viewable to: All, participants: 22

View Respondents

Do you like it when sites have skip links?

View Answers

yes
13 (61.9%)

no
1 (4.8%)

I don't know
3 (14.3%)

sometimes
4 (19.0%)

Would you use skip links if they were available at Dreamwidth

View Answers

yes, all the time
1 (4.5%)

yes, on some pages or occasionally
15 (68.2%)

only if they are visible
3 (13.6%)

no, they aren't useful to me
3 (13.6%)

other, which I will describe in comments
0 (0.0%)

If you would use them, could you explain how you access the site?

View Answers

With a screenreader
2 (10.5%)

Visually but with zoom/magnification
6 (31.6%)

Visually without substantial magnification
6 (31.6%)

Other
5 (26.3%)

denise

One of the problems we've been running into lately when talking accessibility-focused design is that it's very hard to know what assistive/adaptive tech people are using to access the site. Sometimes this information shows up in the Google Analytics aggregate data that we look at for information on browser capabilities, but it's hard to get an accurate picture that way: a lot of adaptive tech self-reports as something other than it is in order to "trick" websites that do browser-specific design into giving it different results, etc.

So, in order to a) make sure we're testing things in the most commonly-used assistive technology setups out there and b) make sure we're making the right design choices in the future (especially as there are multiple conflicting accessibility-related paradigms), we would like to get a better picture of what kinds of assistive technology our users are actually using to access the site.

Rather than trying to make a poll and listing off various forms of assistive tech (and invariably forgetting half of them), let's run this as an open-ended semi-poll. If you use any kind of assistive technology (screenreader, text-to-speech software, dictation software, screen magnifying software, browser extensions or plugins that change the way web pages display to you -- anything at all), please comment to this post listing off all the things you use. (And, if it's software, include the version number as well, if you can find it -- there are major differences in how different versions of some programs work.)

For "assistive technology", we're taking a very, very broad definition -- anything from "JAWS, version 13" (screenreader software) to "Dragon NaturallySpeaking" (dictation software) to "NoSquint" (Firefox extension) and anything in between. If you use it to help you make the web more accessible for you, we want to know about it, no matter how minor you may feel it is. (And even if your particular assistive technology has been mentioned already, mention it again; we'd rather have something reported multiple times than risk missing it!)

For those who feel uncomfortable talking about this publicly, anonymous commenting is enabled in this community (with the antispam test temporarily disabled) and all anonymous comments will be screened on this particular entry, so if you comment anonymously, it won't be public. We don't need to know who uses what particular setups, we just need to know what setups are being used, if that makes sense!

foxfirefey

Global Accessibility Awareness Day Home Page

foxfirefey

The University of Athens Speech and Accessibility Laboratory has compiled a directory of free assistive technology software - applications it has installed and tested and presents on its website.

(Should there be a resources tag? Or should I not make posts like these!)

denise

I'd like to welcome

deborah as the

dw_accessibility project co-leader! She joins the immensely capable

rb, in an effort to increase the good kind of redundancy and make sure that everybody's got support and backup while they're working on making DW awesome.

Deborah's been the programmer most interested in accessibility-related bugs for ages, and in this role, will be concentrating on bringing accessibility best practices into feature design and development from the ground up, as well as on accessibility testing and accessibility research. She's already been doing most of that unofficially, so we figured it was time to give her a fancy title to put on her resume ;)

As always, if you have any accessibility-related suggestions or concerns, you can bring them up to

deborah and

rb, or post about them here!

sophie

I was musing on Bug 4425 (Make "click on subscription line to toggle the checkbox state" work in more cases) just now. Basically, the issue here is that when you have a page that allows you to choose tracking notifications pertaining to another account, such as the tracking page for dw_accessibility, some of the text of the notifications, such as "Someone comments in

dw_accessibility, on any entry" are only clickable on the part before the user tag, and not after. This is because the <label> tag gets cut off before the user tag so that clicking the link doesn't toggle the checkbox. As another result of this, screen readers are unlikely to read the notification text pertaining to the focused checkbox correctly.

This is obviously a problem, and it needs to be fixed. I want to file it as a separate bug, but before I do, I wanted

dw_accessibility's opinion!

There are a couple of solutions I thought of:

One solution is to make both parts clickable separately, which would involve assigning two <label> tags instead of just one. While this would fix things for visual users, it wouldn't solve the existing issue that screen readers are unlikely to read the notification correctly when tabbing to the checkbox.

Another solution could be to remove the user links entirely, and just have the username as bolded text. This will fix the original problem, and it also has two immediate advantages that I can see: firstly, we would now be able to have just one <label> tag spanning the whole thing (at least in those cases; unfortunately it still wouldn't work for notifications that involve dropdowns), allowing screen readers to read it properly. Secondly, It gets us one step closer to having a consistent number of tabs between each listed notification, which makes it a bit more efficient.

I prefer the second solution, as this would seem to be more accessible, but I wanted to find out if this is even a problem for anybody first. I suspect it is, but not being a screen reader user, I don't know.

If you have any better ideas, please let me know! I'd also be interested to know what you think of the situation where dropdowns are involved; the same problem applies to them (the <label> tag is cut off), except we obviously can't reduce them to pure text in this case. What do you think?

deborah

Just a heads-up for people who rely on alt text to navigate the page that as of the next code push the alt text for userpic icons will be changing. When that code push happens (I'm not sure when it is scheduled) the alt text for user icons will become "username: description (keyword), comment". For those who care, the title text (which in most browsers is accessible by hovering the mouse over the icon, but not accessible to keyboard, screenreader, and many smartphone users), will be "username: keyword, comment (description)".

This change will make sure that the same information is available in alt and title, so that people who can hover the mouse to see the title text won't have access to any different information than those who can't. But at the same time, it prioritizes the order of that information according to the opinion that seemed prevalent when this community was polled: people who don't use the alt text mostly seem to be prioritizing the description, while people who use the title mostly don't seem to want the description but do care about the keyword. (While at the same time, a lot of screenreader users would like the description to be available in standard browsers so that sighted folks get more of a sense of what makes good alternative text.)