dw_accessibility | Recent Entries

G'day Accessibility Peoples,

Today we have cool icons about Dreamwidth accessibility for everybody to share!

I've just uploaded a bunch of icons to this community - two of the Dreamwidth Sheep in a wheelchair, and two others with the text "I helped make Dreamwidth accessible". They were made for us months ago and I hopelessly forgot to upload them - I'm fairly sure it was

zarhooie who made them but I may be wrong. Major apologies about that if I am wrong - I hope whoever made them can confirm for me!

In any case, just being here means you're helping make Dreamwidth accessible, so anybody who wants to use any or all of those icons is very welcome. You can grab the icons from the dw-accessibility icon page.

As a bonus, just now

zarhooie is offering to make personalised Dreamwidth volunteer icons for anybody who's a volunteer - which means you, if you want one. Follow the link for her post, which includes a picture and great visual description of the icons she's making. They're spring themed because it's spring in the northern hemisphere right now. Down here in Australia it's the end of summer and everything is brown and dried out from the heat so a spring theme seems rather incongruous, but the icons are still fun!

Enjoy!

Cheers,
Ricky

Current Mood: accomplished

jesse_the_k

Howdy! Thanks to the useful comments on my previous post, I've revised my proposal and inserted it into the DW suggestion generator. Please leave comments and vote in the poll at the

dw_suggestions community.

However, that channel doesn't support HTML tags, so I'm duplicating my post here so I can present my case visually as well as in text. ( so I can present my case visually as well as in text )

Current Mood: hopeful

jesse_the_k

Howdy oh wise ones. There have been some juicy 200-comment threads lately, and I've been running up against a usability issue. I've drafted a post for the Suggestion Generator, and I want to run it by clearer minds than mine first.

So: can you understand what I'm talking about? If you're a large-print, audio, or small-screen user, does this match your experience? Does my proposed solution make things any better? Have at it!

=== begin draft suggestion
Title: Style Comments Page with Outline Indicators in Place of Indents

Summary: Improve UX for reading comments where indention implies structural hierarchy

Full Explanation: The structural hierarchy of comments -- who is replying to whom -- is implicit in the amount of white space between the left screen edge and the start of the comment. (How the comment begins varies, depending on the page's style: could be the words in the comment itself, or the user icon, or the optional subject title.)

For some users, inferring indention is difficult: large print, audio, phones, and other smaller-screen devices.

I'm a large print user, so I'll speak from my experience: It's easy to lose the context of long discussion threads, even with "style=light". (By the way, the help docs mention "format=light" not "style=light": which is preferred?)

The screen grab at this link
http://i277.photobucket.com/albums/kk58/jesse_the_k/SharedPix/LosingCommentContext.png
shows the problem: it's like browsing the web through a soda straw. There are two comments in the middle of a long thread in a Firefox/Mac window with fonts at 20 pt. The earlier comment uses 2/3rd screen width; its reply is indented 1/4 in further. Vertically there's 14 lines of text plus two "header" lines containing user icons, subjects, usernames & dates.

My proposal is to provide a style that makes the outline of comments explicit with printing characters instead of implicit with indents.

I think alternating digits and alpha would suffice; the result would be prepended to the "subject" string, or *be* the subject string if none is present (which would also provide a handy way to reference comments...) An example follows

0. Original Post Subject Line
1. Base-level comment
1a. alpha's response
1a1. beta responds to alpha
1a1a. gamma responds to beta
1a2. epsilon responds to alpha
1b. gamma responds to alpha
2. epsilon responds to OP

Choosing to use it:
http://www.dreamwidth.org/manage/settings/?cat=display

I suggest three tick box options where the current choice is "View comment pages from your Reading Page in your own style":
View comments pages from your Reading Page
1. in your own style
2. in lynx/mobile style
3. in lynx/mobile style with comment outline format
(and it would be wonderful to have a hyperlink from "comment outline format" to a sample of it applied.)
=== draft ends

Current Mood: curious

jeshyr

We finally have a light-on-dark site scheme available - it's called "Gradation Vertical" and has the site menu up the left side of the screen instead of in a bar across the top, as well as a dark background with light coloured text.

This should be helpful for those who find it easier to read web pages with a dark coloured background!

You can try it out by changing your account's display settings.

If you find any problems with it, please let us know by opening a support request and explaining the problem as exactly as you can. Make sure to tell them about any assistive tech you're using if it's relevant to the problem.

Thanks to

branchandroot, who did the light-on-dark scheme. Getting a light on dark version of one of the more horizontally arranged style schemes is also on the agenda in the longer term. Anybody who's interested in helping, or learning how to help, would be very welcome, just leave a comment!

Cheers,
Ricky

jadelennox

People put a lot of work into custom mood themes, and currently there's no way to describe those images in a screen reader, because the alt text is for the mood, not the image accompanying it. I can't see much reason to have detailed alt text for the site mood themes, because it would just be something like "happy -- bouncing smiling star" or "sad -- crying star". But would screen reader users find it helpful if there were a way for custom mood themes to add descriptive text to the images? For example, if there were a Smallville mood theme, the text would say something like "happy -- Clark smiling at Chloe" or "sad -- Lex when his car is destroyed".

I can see how that would be fun, but I could also see that would be lots of pointless noise. Do any screen reader users have opinions about this one?

denise

I've just filed bug 2124 as a medium-term goal to improve the journal customization process for people using screenreaders or people with low or no vision, to provide descriptions of each system style. This way, people with low/no vision will be able to have descriptions of each style read to them, allowing them to choose what they want their journal to look like to sighted visitors.

I'm the first to admit that I don't know what would be useful as opposed to what would be annoying, though, so I toss out the question: what would be useful? What would be annoying?

Text of bug behind cut tag for those who find Bugzilla hard to screenread:
( Read more... )

kaigou

I've been working on a layout (you can see it on my journal, currently). The design's purpose is to separate out the meta of a post and set it to the side, for quicker scrolling/viewing. The working version has this meta-column on the left, with the post's body on the right.

After arguing with various browsers about how to get this to display consistently cross-browser, I ended up going into the base layout and rearranging so the meta comes first in the HTML. That gets me around the issue of floats and so on, but it means now if you're on a screen-reader (from my understanding of how they work, at least) that the reader will give you title, date, and then all the meta and *then* give you the post's body -- after which the reader won't jump back to the top to give you the options again. That second part is easier to address (but not in place yet), by duplicating the post's basic options (comment, edit, tag, etc) as the post's footer. The first part could be resolved by a hidden in-page link, and here's where I'm seeking suggestions (and also information for setting up guidelines for any similar styles down the road).

Here's what seems like the options, to me, but feel free to suggest others if you can see a better path. (I'm working under the impression none of these exist in a current style, since I can't see any sign of them in the code.)

1. Insert the hidden link at the immediate end of the title-text.
2. Insert the hidden link at the end of the title-section, that is, include the date/time line prior to the link.
3. Put the anchor at the start of the entry's body -- that is, include user-name, icon-text, and then read the post.
4. Put the anchor at the start of the actual entry-content.
5. Do both.

Doing the link(s) and anchor(s) are straightforward. It's just a matter of where to put them to make it easier for screen-readers to logically jump from one point to the next, and whether there's likely to be enough variation in what users want to justify hiding multiple links in there.

Additionally, it seems like there's two different types of links in here, one that skips-to-content (#4, anchor at the start of the actual entry-content) and one that simply skips the meta/menu (#3, anchor at user-name). I can see instances where a user might want the first (such as the user's own journal) versus the other (the user's reading page), but I can also see instances where someone who wants to move quickly from post to post would want to use the first (title to content) even on a reading page. In that latter case, as long as I'm linking all over the place, would it also be helpful to have a hidden link at the end of the title that says "skip this post & move to next"?

Thanks in advance for help & input!

codeman38

I just accidentally deleted one of my posts-- which, in a hilarious fit of irony, was a post in

accessibility_fail.

How? Quite simple, really. On the Edit Entries page, the "Save" and "Delete Entry" buttons are right next to one another. And the only confirmation upon clicking "Delete Entry" that that is, indeed, what one really wants to do, is a JavaScript alert box. Combine that with a trackball-based phone interface, an older phone which doesn't understand JavaScript 'onclick' attributes, and a clumsy

codeman38, and, well...

In short: the confirmation for "Delete Entry" should NOT be dependent on JavaScript! If JavaScript is disabled, there should instead be an interstitial confirmation page of some sort.

denise

Was thinking about the alt text for user icon heads and how we could change them to be better and more natural for screenreaders. I've opened bug 2037; the first comment says:

The userhead icon alt is [info - user] and the community is [info - community].
Change to [user profile] and [community profile] for more natural flow in
text-to-speech.

I'm trying to check that this is a change that would be useful. A friend of mine who uses a screenreader says that "user profile" and "community profile" would be the best mix of clarity and brevity and that the best thing to do is to make the first word the key word. But I wanted to post here to make sure that I haven't overlooked anything.

Thoughts?

jadelennox

I'm going to add this to the "to document" wiki, but people should understand that the "title" attribute is not a tool to convey accessibility. Most users, screenreader or not, never see title attributes.
- Survey of results of assistive technology users testing title attribute access.
- A series of essays on "The title attribute - what is it good for?"
Except in form controls, title attributes are useless to 99% of users -- including sighted users, since most people don't hover long enough to see the tooltip.
WebAIM has published the results of their second screenreader survey. Summary of things that interested me:
- JAWS is still in the lead, but NVDA and VoiceOver are gaining.
- IE7 and IE8 are most common browsers, alas.
- most people have JavaScript on
- The answers about alt text are complex.
- The most annoying accessibility problems that would be a problem on dreamwidth are poorly named link text, keyboard access, and bad forms.
- On a lengthy page, many users navigate via the headings on the page.
- There is no typical screen reader user.

zvi

I went to Accessibility Camp DC on October 10, and I got swamped with a lot of information. I haven't absorbed all of it, but I wanted to do a write up and share what I could parse out from my notes and a lot of URLs that I hope will be helpful. Other attendees have shared their presentation slides and blog entries and the conference provided a variety of accessibility links.

One of the sponsors of the program was DC's Martin Luther King Library Adaptive Services Division. I don't know how many people are close enough that getting there is useful, but the library has a wide range of accessible software and devices that they allow people to use, so if a DC-area developer or designer in the area needed or wanted to test how their component actually functions with adaptive technology, going there is a possibility.

The practical advice that I walked away with was this:

In addition to making our user facing tools accessible, we should also work on making the administrative tools accessible
We should develop or adopt best practice policies, so that developers and designers know what we expect them to do to make our tools and website accessible before they start creating an interface, instead of designing the tool and then bringing it here to get checked

Form fields have labels
Links have meaningful text
If information is popped-up or brought forward with ajax/javascript/ruby, etc., it should be brought to the attention of the screenreader and manipulable via keyboard and other non-mouse devices
tabindexing should be explicitly declared if the default reading order does not make sense, but it's best if the default order of links (by which is meant the order that they appear in the HTML code, which can be very different from the appearance of a graphical browser with CSS and javascript turned on) makes sense

The best way to get our users to generate more accessible content is to give them tools that prompt them for accessible choices and explain why they should make those choices, as they make the content.
Keyboards are not the only alternative input device to the mouse. (Unfortunately, the gentleman who made this statement didn't expand on what other input devices one might design for.)

I also got a bunch of links. The most important one for Dreamwidth, I think, is to the Authoring Tool Accessibility Guidelines. These guidelines focus on making the tool themselves accessible and creating tools that generate more accessible content. This is a very technical document.

The WCAG 2.0 Documents
: The Web Content Accessibility Guidelines are the W3C recommendations for Accessibility. They have several interrelated documents which offer different kinds of technical guidance, from general principles to a quick accessibility techniques reference.
Just Ask: Integrating Accessibility Throughout Design: This is not a design book and it applies to electronics and technology generally, as opposed to Web and Internet technologies exclusively. It's about how to integrate people with disabilities into the design process.
Validator.nut: This validator will check HTML5 and ARIA in the same document. For the moment, the W3C validator marks ARIA markup as invalid.
WebAIM: WebAIM's mission is to expand the potential of the web for people with disabilities by providing the knowledge, technical skills, tools, organizational leadership strategies, and vision that empower organizations to make their own content accessible to people with disabilities.
WebA11y: A personal website by Becky Gibson, Web Accessibility Architect at IBM, which has some demonstrates of accessible AJAX and RIA=ARIA.
System Access To Go: Windows only, internet based screenreader. It involves a download. I don't know the size, as I use Linux.

One presentation I attended was on ( performing an accessibility audit )

rho

Hello wonderful accessibility team!

We're in the process of designing an entirely new FAQ system at the moment, and one of the things that I'm keen to do is make sure that we have accessibility considerations built in from the start. Unfortunately, I'm not at all knowledgeable when it comes to accessibility, so I don't know what we need to be looking at. If you could go take a look at this entry from

dw_docs where I have a first draft version of the specifications for the new system up, I'd appreciate it. I need to know:

1. What of the current spec will be bad for accessibility.
2. What of the current spec have I managed to get right, accessibility-wise.
3. What have I just not thought of at all that needs to be added in.

Thanks!

jadelennox

I've made a modified version of the account creation page in order to address bug 1016. I've tested it with JAWS 10 and nVDA, but I know my experience testing as a sighted user is imperfect and doesn't really produce the experience of knowledgeable full-time screen reader users.

I'd love to get several testers trying out this page, with only a multitude of testers with a variety of tools. Because the new page uses WAI-ARIA accessibility encoding, it will have extra features that are only available to people using the newest tools(for example JAWS 10). However, it should still be reporting accurate errors for people using screen readers that don't have WAI-ARIA functionality.

If you are a screen reader user, I would love it if you test that page. Try a bunch of things. Try to create accounts both correctly and incorrectly. Try to create accounts with bad passwords or usernames you've already used. Let me what works and what doesn't!

(You should know something I discovered to much frustration during testing: if you test to make sure that it insists you be over 13 based on your birthday, and then you try again with a much older birthday, the system has a timeout to make sure that you aren't just gaming the system and changing the year of your birth.)

Let me know how the tests go, and tell me what screen reader/operating system/browser combination you are using.

Thank you so much!

jadelennox

I just wrote up a whole lot of note about WAI-ARIA and posted them on the wiki.

jadelennox

(crossposted to

disability)

webaim is running their second ever Screen Reader Users Survey. The first survey has been invaluable to web developers who want to write to how PWD actually use extensible technology, instead of writing to how standards designers think we use accessible technology. If you use a screen reader, please take the survey!

zvi

I have registered to attend AccessibilityCamp DC, and I just wanted to ask if there were any topics people specifically would like me to report back on, if they are presented. I also wanted to mention there are still tickets available for the event.

(I'm going to be out of town and away from the internet starting about midnight EST tonight until sometime next Friday afternoon, which is why I'm asking so far ahead of time.)

snakeling

Hi! I'm trying to work out what the best way to indicate visited links would be, as per bug #1386.

( This got long. )

jeshyr

I know a bunch of readers here use the very plain Lynx site scheme. This poll is for those who use the Lynx site scheme on Dreamwidth (or LiveJournal, etc.) some or all of the time...

We've wondering about defining separate colours for hover or focus.

Mouse users: this would mean that a link would change colour if you put your mouse over it without clicking on the link.

Keyboard users: this would mean that a link would change colour if your keyboard focus got to the link. This would be in addition to the outline which is already present as you move keyboard focus.

Poll #1328 Lynx & Focus/Hover Colour

Open to: Registered Users, detailed results viewable to: All, participants: 10

View Respondents

Would you prefer the Lynx site scheme to use a separate hover/focus colour?

View Answers

Yes please, it would help with accessibility for me
2 (20.0%)

I prefer them, but they don't affect accessibility
3 (30.0%)

I don't really mind either way.
4 (40.0%)

I'd prefer not, but it doesn't affect accessibility for me
1 (10.0%)

Please don't, I find they make accessibility worse for me
1 (10.0%)

I have a more complicated answer I'll explain in the comments
0 (0.0%)

Please leave comments as well as using the poll. What's good/bad about it for you?

r

cesy

I was talking to someone (at http://dw-styles.dreamwidth.org/10503.html?thread=239879#cmt239879) who wanted more light-on-dark styles for accessibility reasons. I've started creating some and posted them in Dreamscapes (all called Light on Dark). Is anyone from the Accessibility team free to test them? I've basically gone for something fairly plain and with maximum contrast, but do say if they're either too ugly, or if my attempts at prettifying have reduced the contrast on the headers and things too much.

( Practical details for testers )

jadelennox

I can't think of any UIUC people at DW -- anyone near Urbana? There's another accessibility conference: Illinois Web Accessibility Conference on September 29th in Urbana, Illinois.