Access filter page

[snakeling]

Hi! I'm currently trying to write the FAQ "How do I set up access filters?", and I'm having a hard time doing that without sighted language, so I'd love it if people who use this page with non-visual browsers could help me out.

First, is there any alt/title text using actual words on the "> >" button used to add journals to the filter? The source of the page was most uninformative on that matter (I hate parsing JavaScript; whoever came up with that language should be taken out and shot).

Second, as it stands right now, the FAQ reads as follows:

When making a locked post, you can restrict its access to a subset of your access list.

Go to the Manage Filters page. Create a new access filter and give it a name. Select it in your list of access filters, then select the journals you want to add to that filter from the "Not in access filter" list and add them with the "> >" button.

You can remove journals from the "In access filter" list using the "< <" button.

Is that clear enough, or is there something else I should add? I'm given to understand that the Manage Filters page is very bad from an accessibility point of view, but we have to work with it right now :/

Thank you for your help!

Comments

[we_are_spc]

It's clear enough for us, but just to be on the safe sid you might want to make it the "ad>>" and remove<<" buttons respectively.

But maybe I'm making it too obvious...? I don't know.

-P

[snakeling]

Thing is, there's no "add"/"remove" anywhere on the page, so it might confuse some people.

Thanks!

[codeman38]

Why not change the button labels to something like "add >" and "< remove"? It'd be better for accessibility in a number of ways that way.

[sophie]

I filed a bug for this yesterday as I noticed we hadn't yet done this, and it's now been fixed in the codebase, so the next code push will have the buttons showing ">> Add" and "<< Remove". :)

[edited: The labels were slightly wrong to what I thought.]

[not_a_sniglet]

As for point 1, I'm not sure what you're asking. Are you asking if there's text on the button now?

And Point 2, that looked fine to us.

[snakeling]

I wanted to know how non-visual browsers described it, ie whether they did something else than saying "greater greater", but apparently they don't :/ (And I could have been clearer; that's what I get for posting in the wee hours of morning.)

Thanks!

[jadelennox]

The button with the angle brackets isn't using an image, it's a textual label. So Jaws, for example, reach the button label as "greater greater", and will do exactly the same thing with the text in the documentation. I think you should be safe, then, using the same label as you do in your FAQ quoted above.

So I think it's pretty clear.

[snakeling]

reach the button label as "greater greater"
That's... really bad.

I had a hard time describing the necessary actions using non-sighted language, but actually, people using non-visual browsers would find it equally as hard to actually use the page, wouldn't they?

Thank you for your help!

[lightgetsin]

Actually no, not really. It works for you, Jade, because I'm assuming you're using Jaws on default settings. But if you tinker with the punctuation verbosity like I have, you don't hear < and >. They're not spoken at all. So to me it's just "button." Most Jaws users I know turn a lot of punctuation off like that because it gets very annoying.

I was going to suggest when I got around to it that those buttons be given actual text labels. Which doesn't help with the documentation question. I think it's fine for now, though.

[jadelennox]

and there, in a nutshell, we have the primary reason why actually disabled accessibility testers with a slew of different adaptive technology needs is such a good idea.

Although the greater point for this particular document stands, as you say. Since the buttons are pretty much inaccessible, you might as well do the best you can indicating the labels that you've got.