Accessible Layouts

[kaigou]

Title:
Accessible Layouts

Area:
Identifying accessible layouts

Summary:
It'd be good to make it easier on folks with vision issues (or who use handhelds) so they can quickly and easily find layouts suited to their purposes.

Description:
I presume eventually DW will follow LJ's path of having provided layouts tagged (seasonal, colorful, minimal, etc). I think there needs to be a tag for users with vision issues, so they can quickly and easily find layouts that are usable with screen readers, screen magnifiers, even handheld devices. (The latter two work best with single-column layouts.)

The same tag, or an overlapping tag (meaning some layouts would qualify as both), would sort out the high-contrast or reverse layouts (stark white on black, stark white on wordperfect blue). Then another tag for layouts with default fonts greater than 14px, and a tag for low-contrast layouts, for users who actually *get* vision problems from too many high-contrast designs.

So there's the categories: vision-accessible, high contrast, low contrast, single-column, and large-font. If I were really dreaming, I'd suggest DW contact its user-comm for blind/vision-impaired users and invite them to be panelists/judges for reviewing/nominating which layouts are "screen-reader-friendly" versus "screen-magnifier-friendly". That way, layouts with that designation really are tested as being good for those purposes, and not just because a good-vision person (like me) says it looks like it satisfies the basic requirements.

(For more info and a great example of designing vision-friendly, see the BBC's info pages on accessible layouts: http://www.bbc.co.uk/accessibility/. It's a wealth of information.)

Poll #998 Accessible Layouts

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
42 (89.4%)

Should be implemented with changes.
2 (4.3%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (6.4%)

(Other: please comment)
0 (0.0%)

Comments

[afuna]

Very strongly in favor of this :)

It's already possible technically. And I think we could start the process by posting to dw_accessibility.

(Also, I wasn't aware how much you already knew! I should have waited for this to show up before replying to your PM)

[kaigou]

Ehehe, yeah. I mostly do interface architecture and process analysis, so I tend to pay attention to things that trip people up -- like icons, font sizes, and color uses. Eventually I guess it just gets to be second-nature, or something.

I think the real issue just hinges on whether or not it'd be possible to get a group of folks who use the technologies to confirm that layouts really are tech-friendly, before tagging a layout as such. Though if there are users who attend university, they can usually do the check as well, if they can get access to their university's accessibility labs -- most fair-sized universities have at least one machine with a screen reader or magnifier. EDU sites are required by law to be 508-compliant (as are all recipients of significant govt funding), so they usually have a way to test -- plus to have it available for students to use who need such tools, which can be pretty expensive software. So there are options out there, for testing a design for true accessibility.

(And we haven't even gotten into the question of localization, but that's a backend issue.)

[msilverstar]

I would love to see a layout with big fonts by design!

[kaigou]

I want one even more after just three minutes of using Safari to browse DW -- for some reason, DW + Safari = 8pt font. Ow!

[ninetydegrees]

DW doesn't use a default font size so it lets you use browsers' default font sizes, which are usually very small if one hasn't set a minimum font size, even for people like me with no vision issues. I know I've seen this issue discussed somewhere but I can't remember where. Sorry.

[kaigou]

It's because most browsers, out-of-the-box, have a default font size of 16px (which is why we can set base font for a page at 1em and then whittle it all down with 90% and 80% navigation and so on). Most folks never reset that base setting, so many designers will just say "font-size:100%" and let the user's own browsers set the base point upon which the relational fonts get built. The problem is that Safari doesn't have a default font size; all it has is a minimum font size -- and in the absence of a site providing its own default font size, the minimum size is what you get. That would be 9px for me. Ow!

(Which is kinda moot since I've learned not to up the minimum -- b/c then when I'm doing my own designs, I can get duped into thinking "wow, that's plenty large" and not realizing it's because my own base font is affecting the relational font sizing. Made that mistake once, and wow, was that a hard layout to read!)

[triadruid]

*sigh* No base size? Madness, in this day and age. I thought the difference between IE and FF was bad enough (work wants all our page body text to be 10pt; I insist on relative sizing for accessibility, then cringe at my browsers).

[ninetydegrees]

Firefox does have a default font size but, by default, it also lets sites use their own font size so, because DW doesn't set any - they use font-size:100% as you mentioned, it uses the minimum font size which is 9px and the site is unreadable. I can't remember what the default size of IE is but I think it's 'smallest' so the site looks as small over there with this setting.

[susanreads]

Brilliant idea! Can they also be tested for accessible colours? There's a site (www.vischeck.com) for showing approximately what a page would look like to people with specific colour deficits, but I'm not sure how accurate it is to tell whether link colours are sufficiently distinct.

[softestbullet]

Awesome site! *bookmarks*

[kaigou]

Good point, and good idea. I'm thinking of how I'd organize it on the layouts page, and now I can't recall (Afuna, maybe?) who suggested doing a tag-class called "accessible" -- if that class could be further subdivided, then that's where it'd be best to break out the different kinds (high contrast, low contrast, color-distinctiveness, oversized default font, etc).

Some kind of sub-division like that would help in clarity, too, because it just occurred to me that in naming tags, if layouts with strong color distinction and/or markers (ie text-underline on hover) were mixed in with the rest and I saw "color blindness", I might think it's someone's bad attempt to be witty for "monochromatic scheme" -- that is, that the layout itself is color blind!

Alternately, to make things easier, it could just be a requirement that for a layout to get the tag of "accessible," it must have strong markers for navigation and links. Either the font-color for links is particularly distinctive/constrasty, or the navigation/links are set off in some strong way, with text-underline and bold, reversed background, even larger font (at the very least on hover).

As for colors, I like colorscheme (http://colorschemedesigner.com/) which can take the colors you've got and shift them to show them in a variety of color-vision perspectives. It's pretty nifty, though it does require of the javascript (and flash, too, I think). Plus, exports in several formats.

[denise]

Just to let you know, I'm marking this suggestion as "deferred", just because the suggestion itself is what we call a meta-bug: something that involves a bunch of other tasks that need to get done all in a bundle before the bug could be considered 'resolved'. We try to avoid opening too many meta-bugs, because it can make things difficult to keep track of and it's often hard to figure out when the meta-bug itself is resolved.

We absolutely have started the process of building some accessible layouts behind-the-scenes, and once we have some of those, we'll be sure to highlight them in their own category.