dw_accessibility | Recent Entries

The results from a December 2010 survey of screen reader users conducted by WebAIM.

I've been wondering about this for a while, and just now decided to ask...

Why are tables broken so badly on Dreamwidth? I get that it's for accessibility, but how does removing borders help? How does screwing up the alignment of cells only when one of them contains an image help? (Example: This becomes this [not my entry], but the cells on this entry are aligned just fine.) Edit: That goes for font styling, also. I know <font> is deprecated, but it's hard to get used to using proper CSS on sites where the stylesheets aren't mine to control (not that that's a bad thing, but there's my reason).

I've tried having a screenreader read an ordinary table and then the version of the table that Dreamwidth "fixed" and noticed no difference. So... what exactly is the reason?

jadelennox

the accessibility DC meet up group says:

We are looking for speakers for the next few months for our events.

If you have a topic you want to talk about please contact us at info@accessibilitydc.org with any talk ideas.

You don't have to be local to the Washington, DC or Batlimore, MD area, since we can Skype you in or some other means of video.

More details are at the Online invitation.

We're adding some previews when you're choosing a site skin, and I've been thinking about an appropriate level of information for the alt text.

The alt text mentions the colors, the orientation of the menus, and whether or not the menus use Javascript. Is there anything else that needs to be added, or is there any non-essential information that should be removed?

For reference, here is sample alt text for four of the site skins:

Celerity: Olive and white with vertical non-Javascript menus
Gradation Horizontal: White on black with horizontal Javascript menus
Gradation Vertical: White on black with vertical non-Javascript menus
Lynx: Simple, bare skin with minimal decoration and navigation

denise

I will be speaking this year at linux.conf.au on the topic of accessibility -- a one hour and forty-five minute short tutorial called "Beyond Alt Text: Accessibility for the 21st Century". The description of it is:

( Tutorial description )

In order to gather as much data as possible, I'd like to ask people who interact with the internet with the help of assistive technology to take a short "survey" (okay, to answer a few questions, really) -- I know enough to know that there's no way I know everything, and the more perspectives I can get from assistive tech users, the better.

I'm particularly looking for input from:

* screenreader users (both wholly blind and low-vision users -- the contrast will be valuable!)
* voice input/navigation users
* keyboard-only navigation users
* people with accessibility concerns that don't necessarily need assistive tech (ocular migraines, seizure disorders, autistic spectrum disorders, etc) but who can benefit from accessibility work

Still, anyone who feels that they have accessibility concerns, or who feels like they benefit from accessibility improvements, is more than welcome to fill out the list of questions. The more opinions and perspectives I can present, the better.

Please leave a comment with your answers, or if you aren't comfortable discussing your answers in public, you can private message me or email me (denise AT dreamwidth dot org).

( Accessibility needs survey )

deborah

please forgive me if somebody else is already working on this. I was looking at accessible embedded flash players, and I came across "making video accessible", which talks about, among other things, using SWFObject JavaScript to detect whether or not Flash and/or JavaScript are enabled. If flash is not enabled, the embed is replaced with a link to the object.

I think that would be a huge accessibility win, and it would be one of those accessibility = universal design issues, because I've also seen people who don't have accessibility needs but browse with No Script or an equivalent complain about the way our embeds work.

What other people think? I haven't looked at the embed code at all, and I admit I am incredibly ignorant about the way multimedia works in general.

zvi

Access Camp DC 2010 is this weekend. Registration is open until 5 p.m. Friday.

I went last year, and I think I brought some useful information back to this community. I can't go, and had ignored the e-mails because I knew I couldn't go, but it just occurred to me that possibly one of you guys could make it, so there you go.

denise

Compatibility with Dragon NaturallySpeaking (MSAA)

I do not know enough about MSAA or Dragon to discuss this suggestion intelligently, but I figured you lovely people might, so I am pointing you to it! (I also pointed the OP over here.)

sophie

Hi!

Just a quick note to say that there's another version of the Update page up linked from the latest news post at http://dw-news.dreamwidth.org/24465.html , and like last time, they'll be wanting to hear from anybody with a view to accessibility.

One thing: They're already aware that the new method of moving the modules on the page is currently only available to mouse users, and they're going to be working on that. But I suspect that they'd welcome any ideas on how to do so!

susanreads

I hope this is a suitable place to ask: Is there a recognised semantic markup for distinguishing visuals from audio in a transcript? I've been using [brackets like this], but I doubt screen-readers pronounce them. I can make text appear in italics with em or q or cite tags, but I don't know whether any of those are distinguishable in other formats.

ninetydegrees

Hi,

I'm a style developer and I would like to ask the advice of screenreader users about the positioning of the Navigation module (i.e. links to Recent Entries, Reading, Archive, etc.). Several styles display this module in the 'header' area. However, its actual place in the source code varies from one style to another and I'd like to know what the optimum place is for you. Let me link you to examples:

1) Link to example 1. This is the Transmogrified style. In the source code, the navigation module is below the journal title. It's also displayed there.

2) Link to example 2. This is Modular. In the source code, the module is above the journal title and subtitles. It's also displayed there.

3) Link to example 3. This is Bases. In the source code, the module is below entries while it's displayed above entries, below the journal title and subtitles.

4) Link to example 4. This is Crossroads. In the source code, the module is in the sidebar, below the profile module by default while it's displayed at the top of the page, above the journal title and subtitles.

Would you tell me what the best place is for you, please? Suggestions and ideas about other possibilities are welcome, of course. :)

hope

Hi,

dw_accessibility!

fu and I have been working on building the next version of the update page redesign, and making sure our markup is as accessible as possible.

With that in mind, we have a question with regards to the use of fieldsets that we hope you can help us with.

( details below the cut )

Update: This news post links to a live version of Mockup 1.

denise

I'm trying to make a list of pages or workflows that need redesign over in

dw_design, and thought I'd add a comment here as well, since redesign for accessibility is just as important as redesign for usability.

If you have a few seconds, please let me know what pages need help!

deborah

A periodic reminder: tell us what accessibility needs aren't being served by dreamwidth and we'll see if we can make them happen. Be pie-in-the-sky. It's unlikely that dreamwidth will be able to be your bionic ears or will be able to give your service animal opposable thumbs, but if it's within the realm of feasibility, let's see what we can make happen.

Or if you are shy you can just talk about it here, or even just private message me.

anarres

Hi all, I'm one of the Google Summer of Code students, working on the statistics project. I've written a module that generates graph images, which will be shown on http://www.dreamwidth.org/stats/site. I wanted to get some feedback on the images from an accessibility point of view. I don't know much about accessibility, but I guess the main questions would be, are the colours on the pie chart different enough to be distinguished by people with partial colour-blindness, and is the text visible enough?

The graphs module is found in an uncommitted patch here: Bug 2699 - Create a graphical front-end for the statistics system.
( read more )

deborah

There's been a brief but meaty discussion going on in bug 2773 about what we should put in the title attribute of image elements used for userpics. This is only tangentially an accessibility issue: most screenreader users and all keyboard-only users never see the title attribute (screenreader users can configure their screenreaders to read the title attribute, but I've been told this is rare in practice). However, it was a conversation around accessibility which led to some concerns about userpic's use of the title attribute, as it was very difficult for non-screenreader/text-only browser users to have any idea of what descriptive text was for userpics. That descriptive text (the "alt" attribute) was information to which several users wanted easier access.

( Long introduction about what the title attribute is )

( Title in DW userpics )

So after that ridiculously wordy preamble, here's a proposal:

title = "Image keyword: " + $keyword + $description + $comment

In other words, the title, primarily available as a mouse-hover tooltip, should contain the image keyword, the alt text description if available, and the comment if available. On the one hand, this might make for somewhat long hovers. On the other hand, descriptive text shouldn't be getting crazy long anyway.

What do people think? This is clearly a usability design issue primarily for people who use the mouse-hover feature. Again, its accessibility issues are primarily tangential, in how we can potentially expose high-value accessibility features to people who don't need them.

deborah

Hey, gang. This is a question both for screenreader users and for non-screenreader users, because the answer will affect both groups.

I'm looking at bug 2083, which deals with redundant information on sticky posts. The core of the problem is this: if you have a sticky entry which always appears at the top of your journal, it gets a special icon (a star) before the name of the post. The star icon has the alt text "[sticky entry]". Additionally, the style system by default prepends "Sticky: " to the subject line of the entry.

It's been pointed out that this provides redundant information to screenreader users or anyone else who is relying on alt text instead of images. The problem is that the subject line text is configurable in the style system (appropriately!), so it can't be guaranteed to stay there.

One option is to remove the alt text from the star icon, but that doesn't work if the user configures their style to remove the text that says "Sticky: " from the subject line.

One option is to remove the default "Sticky: " from the file system, so that the default state of the sticky post is not to say the word. This would remove the redundancy for screenreader users, but I think it would come at a cost. The star icon isn't so obvious or so frequently seen that everybody who sees it will immediately assume "oh! That is a sticky post!" So for users who benefit from images, I think there is a real benefit both to having the icon and the text.

So here is a case where it feel like usability for those who benefit from images is actually in conflict with usability for those who don't. The enhanced usability for the former group causes redundancy for the latter.

Does anyone have any ideas?

ETA: per

aveleh's suggestion, I'm adding some journals that use sticky posts so that you can see examples.

Denise, who left the original style text in place
Zvi, who changed the default style text

chemicallace

I'm working on Bug 2050 and wanted to get the opinions of screen-reader users and others who look at the alt text on images for user icons.

Currently, the alt text for icons is generally the description the user provides for the icon and on regular site pages this is automatically added when the page is generated. On the Dreamwidth staff page, there is no alt text for any of the icons at this time. I try to include alt text in my images on most web pages for both standards compliance and accessibility reasons. However, it's not clear in this situation whether or not having an alt text on these icons with the user name of the icon owner, key words, or a description would be useful or a nuisance. The user name is given in text in close proximity to the image, and any keywords or descriptions would be undesirable on our end because they would need to be hard-coded into the page and wouldn't automatically update when the user updated their icon keywords or description.

Would alt text on these user icons be helpful? Or is it unnecessary and/or an annoyance?

jadelennox

Hey, guys.

fu has coded a mockup of what the new update entry page will look like, and the dreamwidth staff are looking for feedback. This is a great opportunity for us to get our feedback in early on in the process -- there's an actual form for us to play with (although I should note that accessibility was part of the design from the very beginning).

denise has a post talking about the details of the new update form which is well worth reading before you test, or you could just go directly to the create entries demo itself. Screen reader user? Keyboard-only? Zoomed user? Give the feedback no one else will be able to.

Leave feedback here.

Obligatory disclaimer: I had nothing to do with any of this, I am just signal boosting.

jadelennox

One awesome thing which has already come out of our association with Google Summer of Code is our introduction to the developers of Dojo, another open source project. Dojo is a JavaScript toolkit whose developers claim they are the first JavaScript toolkit with full accessibility support in their base widget set.

Using Dojo wouldn't be a trivial decision. Dreamwidth developers have put a lot of work into learning jQuery, and we don't want to move in entirely different direction and less there's a good reason.

So what would be fabulous is if we could get people really hammering on the widgets the Dojo people programmed to be accessible. Try them out -- are they accessible for you? Do they work with your needs, your adaptive technology, your browser? Are they intuitive?

At the same time, we should test the jQuery widgets, to see if we find those any more or less accessible.

This is a valuable test for everyone with any accessibility needs to do, whether you use adaptive technology or not.

I made a page on the wiki for JavaScript widget testing that links to all the tests we should do. There's a lot there! I don't expect anyone will do all of them; goodness knows I tuckered out about three quarters of the way through and I haven't even written up my test results. Still, if people could do some of these tests and report on how well they work for you, that would be totally awesome. You can report as comments to this post or in the various sections of that wiki page. I made sections called "results" after the link to each test, so you can just list the results you had for specific tests.

and thank you for anything you can do, even if it's only brief!