Making the Manage Message Settings page a bit more accessible

[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:

1. 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.


2. 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?

Comments

[lightgetsin]

Oh, so that's why. It is in fact a problem for me as a screenreader user, but I had actually been blaming it on some unrelated browser weirdness.

I agree that option 2 sounds like the better choice.

[deborah]

from a keyboard perspective, option 2 sounds like a better choice as well, because of the thing you mention, Sophie, with consistent number of tabs. It also just feels like better form design.

I'm trying to think of usability reason why you would want to have the name be a complete user tag in that particular instance, and I can't think of a great use case.

What's the example of where drop downs are involved?

[sophie]

Well, for example, when you track a post (and use the "More Options" link if you have JavaScript turned on), you arrive at a page like http://www.dreamwidth.org/manage/tracking/entry?journal=dw_accessibility&itemid=20122 .

One of the options on that page is "Someone posts an entry tagged [dropdown] to dw_accessibility", where the dropdown contains a list of all the tags you can see on that journal or community. I don't think this is the only time it happens, but it's the one that came to mind first. I'll try to find some more, too!

[sophie]

As for usability, there is a usability issue; when going to The Notifications tab in Manage Settings, the same notifications are displayed, and in this case it may well be desirable to have the usernames clickable.

[edit: It should be possible to have the names as plain text when tracking, and the names as links when going to that Settings page, but that's still not a really good solution, obviously.]

[jeshyr]

Consistence is also a usability issue but a cognitive accessibility issue - currently pretty much any username or community name in the site comes in a certain format, and we're breaking that. It's not a small change, cognitively, but I'm not sure if it would be an issue for people or not...

One thing that comes to mind is to change the language so that the drop down and/or username come at the end of the label. For example "Someone comments in dw_accessibility, on any entry" could easily be "Someone comments on any entry in dw_accessibility". If the "different" bits are at the end of the label it avoids the problem of splitting up the label and makes most of it clickable. Would that be a solution that would be workable??

[sophie]

Perhaps, but I'm not sure how the option to track a certain user's posts in a community would be changed. Currently it's "sophie posts a new entry to dw_accessibility", and it would sound a little awkward to put both of those at the end. Otherwise, it sounds like a good implementation of option 1. (Of course, it still doesn't allow screen readers to read the whole thing when tabbing, which isn't good, but no worse than what we already have.)

I guess this whole thing isn't a problem that will be solved easily. :/

[denise]

Oooh, I like this. I think most of the options can be rephrased with a little bit of creativity (and willingness to use the passive voice if necessary!)

Would putting the username in the front or back of the label work too? Like, Sophie, the one you mention (sophie posts a new entry to dw_accessibility) has the usernames at the front and back; the label could go from "posts a new entry to" and stop there?

[crschmidt.net]

For the record, since it appears that this is still somewhat under discussion, I've punted bug 4425 back into the pool for now, since it's probably better suited for someone more aware of the various ways it should happen rather than a trivial bugfix at this point :)

[sophie]

Well, I was thinking that the result of this discussion would end up as a separate bug, leaving the original bug to deal with the initial problem. Of course, they are linked, so I'm not sure if I was thinking in the right direction or not...

[edit: I replied to denise about this - hopefully that makes it clearer what I mean.]

[sophie]

That definitely works in regard to option 1, and I think it'd be a good way to go forward on bug 4425 for now. I also think that while that's happening it would be best to keep discussing this issue and see how we can make option 2 work, because ultimately it's probably the better way of the two to do things. (Of course, if anyone has any better ideas, we could discuss those, too.)