Re: [orca-list] Practise in accessible websites

[Mallory van Achterberg <stommepoes stommepoes nl>]

Hi Julian,

You're limited mostly to what browsers are capable of, rather than
what things like screen readers are capable of, since the browser
passes info on to the screen reader and most other AT as well
like speech recognition programs, screen magnification, etc.

Bleh, I had typed out a mail that was much, much too long. I'll
do little tips instead. Oh god they got big too.

Regarding other OSes, Microsoft has this whole accessibility layer
underlining all or most of its software. This is what IE uses.

Apple has its own thing going as well. So far as I know, VoiceOver
still only works with Safari and no other browsers on the Mac. If
this has changed, it's changed recently.

Regarding screen readers: except the free ones like Orca and NVDA,
most of them are hideously expensive. So unlike browsers, when
keeping users in mind it might be better to assume older readers
are still popular. Actually, just assume if it costs and arm and
a leg, people are using old versions of it.

1. Use as best as you can the correct HTML element for your content.
None of this <i role="checkbox"></i> stuff, do a real <input
type=checkbox"> instead. Use headings for headings, lists for lists,
forms for forms, tables for data, etc. Try to keep non-form elements
outside and preferably before the form (instructions, headings,
stating what distinguishes a "required" field are examples).

2. Most CSS is ignored by screen readers except a few things:
display: none and visibility: hidden will hide content from them.
If you want something visually hidden but available in the document,
position: absolute it and pull it offscreen with a negative left
or left-margin. 
CSS generated content used to be ignored by screen readers, and still
is by many, but for example Mac's VoiceOver announces them, so be
aware of that.

3. Keep various input devices in mind. Assume you get users without
a mouse. Maybe a touch screen. Maybe a chin cup. So everything that
expects user interation, use naturally-focusable elements like anchors
and inputs (if/when that's not possible, you have to resort to things
like tabindex=0 and tabindex=-1 + Javascript). Make clickable areas
physically large enough... for people with fat fingers on touch
screens, or with a pointing device with poor control. One popular
example of this is having your form label's "for" attribute match
the id of its input. This allows the label to also become part of
the input's clickable target area.

4. No pictures of text. Or at least add alt attributes if you do.
I hate this and my current employer is forcing me to make these
(for "SEO reasons"). My soul is sold and gone, but you still have
yours. So don't do this. (I don't mean logos etc. but still for
those, alt text).

5. Use WAI-ARIA. http://dev.opera.com/articles/view/introduction-to-wai-aria/
Most of the time, this can be used without worry: older browsers
and AT ignore it because they don't understand it, but most
newer ones can use it. Landmark roles especially are nice and pretty
easy to do right. With interactive pages though be careful:
http://www.marcozehe.de/2012/02/06/if-you-use-the-wai-aria-role-application-please-do-so-wisely/
As of jQuery 1.9? I think is when they've got aria stuff in the core
by default, which is nice. According to the Web-AIM surveys, screen
reader users tend to have Javascript enabled as much as anyone else,
likely for the same reasons (browsers come with it on by default).

6. There's a range between completely blind and 20/20 vision. Keep your
fonts large, readable, and in a unit other than px if you want IE
users to be able to use text-enlarge (zoom always works but it makes
images blurry so for me that doesn't count as an excuse to use px).
Px should ideally be limited for text who must match an image in size.

There will be sighted people using screen readers. Try to keep your
visual page matching what a screen reader would read out if possible.
Use decent contrast and check with a contrast-checker (there are
plugins for browsers; checking in one browser ought to be enough). 
Users with high-contrast settings in Windows on will for example not
see your background images. They get removed.
Dyslexics may do worse with very very high contrast and it's known
many are tripped up by text-align: justify, so try to avoid that one.

7. Videos? Make captions. And transcripts. Or similar.

8. If you are contactable, don't let the phone be the only way for
someone to reach a human (the deaf are pretty angry with the Dutch
site for work and welfare for this reason). 

9. Avoid auto-play anything. If you're YouTube, everyone knows you
autoplay but also know where the off switch is.

10. Avoid auto-move anything. Some of that stuff makes some of us
literally sick. Ideally all actions from a website should come from
direct and conscious actions of the user. Users should be the ones
activating things, not frantically looking around trying to stop
something unexpected.

Hm. There's much, much more. Look up these terms will help I
guess:
WCAG2
WAI-ARIA
Paciello Group
Filament Group
Web-AIM
http://www.marcozehe.de/ Marco's got some good tips here

There are sites who do tests with screen readers and other things
on multiple browsers/platforms:
http://accessibleculture.org look for ARIA and HTML5
http://3needs.org/en/testing/ Detlev Fischer's site

I have some plugins in Firefox for testing things.
Chris Pederick's Web Developer ToolBar: I can turn on and off
Javascript, Images and CSS to see that what results still makes
sense.
Juicy Studio's Colour Contrast Analyser: test text contrast to see
if it's pass or fail for AA or AAA.

I'm gonna stop here. There are lots and lots of people who can
give you much much more information. On twitter, linkedin, on
accessible blogs and forums and mailing lists. 
-Mallory



On Thu, Oct 25, 2012 at 06:59:21PM +0200, Julien Claassen wrote:
> Hello everyone!
>   I have been wondering, what the best practise in designing
> accessible websites is? I mean, practically speaking, does
> Orca/Thunderbird rather understand/accept aural CSS or embedded SSML
> in the HTML? Or should one leave all those things alone? If someone
> has info on the other OS' side of things, all the better.
>   I'm sorry for the part-off-topic and appreciate any advise.
>   Warmly yours
>          Julien