dw_accessibility | Recent Entries

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: Registered Users, 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.)

denise

I've temporarily set commenting privileges on this community to registered accounts only (no anonymous comments), since it's apparently been put on a spambot network's spam list. Someone remind me to turn it back in a week or two in the hopes they'll have given up by then :)

clefurgey

Just thought I'd pop in really quickly to say hi, and how thrilled I am to see this community.
I'm a relative newby to DW, even though I've had my account here for ages (i'm lazy and don't update my journals enough).
Anyway, I love it here so far, with only a couple minor questions, one of which has nothing to do with DW specifically but I didn't know where else to post it, sooo.
First, I'm using both jaws and NVDA, and they both work really well.
Next, thank you for setting things up so that icon keywords or descriptions get read, I really appreciate it.
Now, for my questions.
1. Is there any way to take the news community off the top of my homePage? If not that's ok, it's not a huge deal, I just wondered.
2. Now, for the question that has nothing to do with DW. Does anyone know how to remove an account from the list of choices when you log into Semagic? I was setting something up the other day and made a mistake, but cannot find any way of deleting the screwed up account.
Sorry that last one's kinda OT, but I couldn't find anywhere else to post it.
Anyway, thanks for any help anyone can give, and I look forward to using DW.

deborah

I've been thinking for a little while about making a DW suggestion about putting in something that makes it easy for people to generate accessible hyperlinked footnotes in their posts. This week, somebody ran this little script to generate dynamic footnotes by the WebAIM mailing list.

I was hoping that people here could give it a try and see what they think. It's a really neat little tool. It requires JavaScript not be disabled, and possibly might require newer versions of JAWS (because it uses WAI-ARIA), but basically it makes it so that creating only a tiny little snippet of code, you can get footnotes that, in a keyboard and screen reader accessible fashion, allow you to jump back and forth between the footnote in the cited reference. He also added a configurable hotkey so that screenreaders could announce the footnote text without changing the page focus. (I tested that with in NVDA, and it worked splendidly.)

What do people think of it?

Demo of dynamic footnotes

jeshyr

A bunch of new accessibility fixes have gone live on the Dreamwidth site with the latest code push! They're all listed in the

dw_maintenance entries but they're mixed in with tons of other stuff so I'm pulling them out to list here for those people who are interested...

( Accessibility wins! )

This code push also activates the very first beta testing of our new Create Entries page! This is a complete rewrite of the old Update page in order to allow for future expansion and new features such as draft posts, scheduled posts, recurring posts, expanding the range of what can be posted to your journal, and a whole host of other awesome things. It's not finished yet - the biggest thing you'll notice missing is the rich text editor (RTE), you have to type posts in HTML if you're using this beta feature.

This you will only see this new beta update page if you turn on beta testing, and you can turn it off at any time. Check out

dw_beta for more details about this.

I'd like to really encourage people who use accessibility technologies of any type, including screen readers, magnifying software, large text, speech-to-text software, keyboard-only access, etc., to try this beta out if you have some spare time and energy.

fu, who is doing the programming for this new page, is very aware of accessibility needs and we all want to get it as accessible as possible so we need to know what's not easily accessible yet! Pop over to

dw_beta and read the post about the new Create Entries page and leave your comments over there so we can keep improving.

Cheers,
rb

codeman38

On the page to enter credit card details for an order, I noticed two small issues that one might consider issues of cognitive accessibility, that seem like they could easily be fixed:

1. Somewhat related to Falsehoods Programmers Believe About Names, the way the name fields are set up doesn't actually match the format it's in on my credit card. The name embossed on my credit card is in the form "John Q Public" (though with my real name, of course), and I'm never quite sure how to enter it on forms that have only a First Name and Last Name field; usually I end up entering "John Q" in the first name field. Unless your payment processor actually requires the name to be separated into first and last, it'd make much more sense to just have a single "name as listed on account" field, in my opinion.

2. My brain sometimes has a hard time remembering what numbers go with what month names. (This is not helped by the fact that the months were named when the year still started in March, so all the Latin root words are off by two!) My credit card lists its expiration date as 07/14, and so on any form where the months are listed by name rather than number, I have to scroll down line by line and count to make sure I have the right month. It seems like it'd make just as much sense to have the months listed as "01 - January", "02 - February", etc.; this is how I've seen it done on a number of other e-commerce sites.

denise

We have discussed, multiple times, how to utilize the varying combinations of keywords, descriptions, and comments on icons. Bug 2773 is one of the places where that discussion has been happening, and there has been previous discussion here in

dw_accessibility: Title attribute and userpics. (There was, unfortunately, no consensus, indicating that -- as always -- one person's accessibility is another person's accessibility nightmare.)

Currently, the description is used as the icon's alt text (viewable/read by screenreaders, text-based browsers, and most browsers with images turned off), the keywords are used as the title text (viewable in a popup when moused over in most graphical browsers; unavailable to screenreaders and most mobile devices), and the comments/credits are only shown on the icons page.

Some of the issues that have been brought up/discussed:

1). Information should never be available to graphical browsers and sighted users that isn't available to screenreaders, text-based browsers, and non-sighted users. Right now, keywords are only available inline to people who can mouseover the icon image and read the resulting tooltip.

2). Web standards say that alt and title text should not be the same. (We're more than willing to ignore standards when standards are wrong, but it's still a consideration.)

3). Making alt text be username + icon keywords + description + comments (aka, combining the existing alt text and the existing title text) would result in hellaciously long alt text that would have to be read out every time.

4). Various people already using any of the four pieces that go into the alt text and the title text right now -- username, keywords, description, and comments -- have come to rely on having that information available, and would prefer it not be removed.

5). Hover text (which most browsers use the title attribute for) can only be reached by mousing over the image (which already excludes a large group of people).

6). Most browsers only keep hover text visible for a short length of time, meaning that long title text would not be readable in the time it stays visible.

With all of that said, please take the poll below indicating which option you'd prefer. There are two polls. One is for people who interact with the site visually/graphically; one is for people who interact with the site purely text-based/screenreader-based. Please only answer the poll that is applicable to you.

The polls are anonymized; everyone will see the answers and who voted for what, but nobody will see a name attached to them. If you have a problem answering the poll, please comment to this entry; anonymous commenting is enabled in this community if you aren't comfortable commenting while logged-in.

(The results of this poll will not necessarily determine what we do, but it will be part of the information we use while we decide.)
( Read more... )

denise

I've just posted an entry to

dw_styles asking for brainstorming on categorizing styles/themes. I'm particularly interested in accessibility concerns, so if you have a second, pop over and give me your thoughts!

sophie

I was looking at the icons page for some friends recently when I realised something; each icon on the page has the description as its ALT text, even though the description is given in the next column over anyway.

(for an example of an icons page with descriptions, see my icons page.)

Since I myself don't use a screen reader, I don't know whether this makes things easier or more difficult for those who do, or whether it impacts accessibility in any other way. One of the aforementioned friends, who is blind and uses NVDA (a free, open-source screen reader for Windows), said that they think it's a little odd and that it would probably be better to use the keywords as the ALT text on that page. (Everywhere else, of course, should still use the description.)

I'd love to get input from a wider audience, though, and particularly from people for whom this sort of thing matters, such as those using screen readers. What do you all think? I'd post to

dw_suggestions but I'd prefer to know the views from the people here first.

deborah

I'm sitting down to work on bug 820, "Conform to WAI-ARIA guidelines throughout site" (two years after the bug was first opened, *hangs head in shame*). Don't worry if you don't know what WAI-ARIA is; suffice to say it's a technology that improves the accessibility of webpages.

The first thing I am going to do is focus on what needs we have that WAI-ARIA can meet.

To that end, I would love it if people took this as an opportunity to name their accessibility problems with dreamwidth, however small. I'm going to go back and look through the archives of this community, and I'm going to look at all the accessibility bugs in bugzilla, so don't feel you need to repeat things which have already been said. But don't worry about repeating accessibility concerns which have already been said, either; I have no problem with duplicates. Also, don't worry about only reporting accessibility issues you think WAI-ARIA can fix -- report everything, and I will figure out if WAI-ARIA can do anything to improve the user experience.

And hey, if it can't, maybe I will take other issues from this post, that don't come under WAI-ARIA, and create suggestions or new bugzilla bugs. Nothing goes to waste around here! :-)

azuire

I understand there's algorithms to generate the html number on entries, and that these aren't consecutive to protect privacy. I'm wondering if it's possible to personalise these to generate numbers that can prime-factorise or end with certain integers (such as 5 or 0?), for those of us with OCD? I know this is an issue for at least two other people besides me.

Thanks in advance!

foxfirefey

I'm on a web accessibility email list at work, so I get a lot of good pointers to resources:

HTML5 Accessibility Challenges: what it includes, how it helps accessibility, and the problems it can cause

meloukhia

Animations and flashing things (including animated user icons and mood icons) basically break my brain and they keep showing up on my reading list, much to my dismay. I'm wonder if it's possible to add an option to the user settings to block all animations on the site (in my innocence about web development, I have no idea how difficult this would be)? I know this is an accessibility need for other people as well.