Archive for the ‘accessibility’ Category

Scripting Enabled Day 2

Sunday, September 21st, 2008 at 5:08pm

Day two of the event was a “hack day” style event, where lots of geeks gathered with the speakers to try and build something useful. There were lots of mini-projects on the go.

I did a bit of hacking with some bookmarklets and javascript to switch to user-defined style sheets, giving the option of looking at any website as reversed video with much larger text, for instance. Here are a couple of screenshots:

[Regular video Flickr,  but with large text]

[Reversed-video style sheet is easier for users with some visual impairments or other disabilities]

I hope to be able to use some of the techniques in future projects.

I was also rather amused  by the tshirt one of the other geeks was wearing:

[Clueless!]

Scripting Enabled Day 1

Saturday, September 20th, 2008 at 4:31pm

I attended the excellent Scripting Enabled conference and developer day recently held in London. It was extremely enlightening about various aspects of the web and how users with varied access difficulties are affected by the decisions us developers make every day.

There were some excellent panels – links to the trascripts, slides and audio etc:

[Kath  hates the interweb!]

[Leonie and Artur talk about Screenreaders and JavaScript]

[The panel takes questions at the end of the day]

@media session 10

Friday, May 30th, 2008 at 3:00pm

WAI-ARIA – It’s Easy

Steve Faulkner

Web Accessibility Initative – Accessible Rich Internet Applications

It’s a W3C spec, close to becoming a recommendatio, aims to make sense out of NOISE, out of silence.

Wherever possible, use the native tags to convey role and state – where you can’t, use the new WAI-ARIA attributes to add extra meaning – this way, the keyboard operability is built in.

Role and state information can be applied to virtually any HTML element. For instance, the extra code for a button/graphic might be:

<a href=”" title=”OK” role=”button”><img src=”ok.gif” /></a>

The extra attribute, role=”button” is the thing which tells assistive technologies more information – the role of the element is a button, and the standard usage instructions fed to the user would be “to activate, press spacebar”.

Of course, the same thing could be achieved with an image button, but WAI-ARIA can still add extra useful information:

Button off-state:

<input type=”image” src=”okoff.gif” alt=”highlight off” role=”button” aria-pressed=”false” />

and for the on-state:

<input type=”image” src=”okon.gif” alt=”highlight off” role=”button” aria-pressed=”true” />

AJAX and WAI-ARIA

It can help in the following situations – when

  1. Users not having access to content changes
  2. Users not being aware of content changes

Eg Twitter’s letters left indicator – when you’re typing in the box, screen reader users don’t know the numbers are changing (they are in virtual cursor mode for text input).

Live Region attribute addresses this problem – pause during typing, and the letters left is announced by the screen readers. The relevent attribute is aria-live, properties are “off, polite, assertive or rude”. So they gain access to content changes.

Support
Major browser vendors, yahoo, google, Jaws, etc. You can start using them now, they won’t break agnostic browsers, it will be ignored.

FireVox is a plugin for FF – you can test it with that?

Attributes can be added by unobtrusive Javascript. But if you put them in now, they might not validate.

Firefox Accessibility Extension – useful for testing without a screenreader. Knows about WAI-ARIA attributes and will indicate state changes etc.

ARIA: Accessible Rich Internet Applications/Relationship to HTML FAQ

Steve’s presentation: slides | audio

Playing Catchup

Thursday, May 17th, 2007 at 11:35pm

I seem to have got out of the blogging habit, so I’m hoping to catch up on a few posts now. I’ll tweak the dates so they’re relevent to the events roughly as they happened (chronology? what’s that?!)

The first event I’d like to make a post about was the excellent -

Web Standards Group Meeting on Javascript

Some of us shy away from JavaScript (until recently, myself included) on the grounds that it’s not accessible. But these days, if it’s done right, it can be positively beneficial to accessibility.

Demystifying Screen Readers – Steve Faulkner
Steve is very knowledgable on screen readers and all their foibles, and is Director of the Web Accessibility Tools Consortium. This talk mainly centred around Jaws (65%) and Window Eyes (35%). The bracketed figures are from a US National Federation of the Blind market share survey – it’s obvious these are the two big players.

The key issues revolve around:

  • Dynamic updates – user initiated and independent
    Can the user access the updated content?
    Is the user aware that the content has been updated?
  • Rich Internet Applications (RIA)
    Can the user understand the role of the control?
    Can the user successfully interact with the control?
    Is the user able to access information about the current state of the control?

He then explained the differences in screen reader modes:

  • Browse Mode (virtual buffer) – the user can navigate page content via paragraphs, headings, links, lists etc. They can also activate links and some form controls. But text characters can’t be input into form fields, or interact with select elements in this mode.
  • Forms Mode (browse mode off) – the user may only navigate through a document to focusable elements via the TAB key. Text access is limited to “read all” functionality. Most of advanced content navigation is unavailable.

The crucial question we have to consider is, when and how does content become available to the user after it’s been updated in the browser?

[Steve Faulkner and the Latency Issue]

Latency is a problem because the virtual buffer does not update and the user doesn’t know anything has changed. However, JAWS v7.1 started “listening” for virtual buffer updates in response to things like:

  • window.setInverval()
  • object.innerText (for IE)
  • object.textContent and object.appendChild (in Firefox)
  • changes in form control values
  • And other stuff like ALT or TITLE attribute value changes.

Jez Lemon has an excellent article on Improving Ajax Applications For JAWS Users on his webiste. Steve summed up with some recommendations:

  • Do not code to accommodate the poor support shown by JAWS and Window Eyes.
  • Use unobtrusive methods where available and appropriate, to help screen readers along.
  • Don’t use the excuse that JavaScript / Ajax is not accessible for screen readers to not bother to design for accessibility.
  • Start developing interface elements that use WAI-ARIA specs, which will provide some benefits now and many more in the future.

Steve’s thought-provoking presentation was followed by a turn from Christian Heilmann entitled Seven Reasons For Code Bloat

[Christain's been on the beanz again]

His notes are available for download from his blog, so I won’t repeat them verbatim. Needless to say, it was a fun presentation and contained the obligatory photo of a kitten ;-) . Meanwhile, he’s thinking of this as the title of his next book:

[Christian's Next Book?]

PubStandards XVIII
Of course, the next item on the social agenda was the PubStandards gathering. Lots of fun and revelry as usual, here’s one photo, but you can see more on Flickr.

[Patrick & Ashe go head-to-head, while Ross butts in the middle]

Mobile Web Best Practices

Tuesday, March 20th, 2007 at 3:55pm

Sheila went to the 3GSM World Congress in Barcelona a few weeks ago, and picked up a handy set of cue cards on designing for the mobile web, which she was kind enough to give to me. It was great timing, since I’d been thinking for a while about the best way to go about designing for mobile devices. The cue cards promote the W3C’s Mobile Web Initiative, and are great prompts on the best techniques to use.

[Mobile Web Best Practices cue cards]
So for those who don’t have a copy, I thought I would share the wisdom that they detail. More info can be found at http://www.w3.org/TR/mobile-bp/ – but the below is a distilled and much more user-friendly summary.

10 Ways To Mobilise
The cards are broken into ten topics, with hints and advice on each:

1. Design for One Web
Content designed with diverse devices in mind reduces cost, increases flexibility, and reaches the needs of more people.

Thematic constistency – ensure that content provided by accessing a URI yields a thematically coherent experience when accessed from different devices.

Capabilities – exploit device capabilities to provide an enhanced user experience.

Deficiencies – take reasonable steps to work around deficient implementations.

Testing – carry out testing on actual devices as well as emulators.


2. Rely on Web Standards

In the highly fragmented market of devices and browsers, standards are the best guarantee for interoperability.

Validate Markup – create documents that validate to published formal grammars.

Content Format Support – send content in a format that is known to be supported by the device.

Content Format Preferred – where possible, send content in a preferred format.

Character Encoding Support – ensure that content is encoded using a character encoding that is known to be supported by the target device.

Character Encoding Use – indicate in the response the character encoding being used.

Style Sheet Use – use style sheets to control layout and presentation, unless the device is known not to support them.

Structure – use features of the markup language to indicate logical document structure.

Error Messages – provide informative error messages and a means of navigating away from an error message back to useful information.


3. Stay away from known hazards

Thoughtful design can help reduce usability problems due to small screens and keyboards, and other features of mobile devices.

Pop Ups - do not cause pop-ups or other windows to appear and do not change the current window without informing the user.

Tables Nested – do not use nested tables.

Tables Layout – do not use tables for layout.

Graphics For Spacing – do not use graphics for spacing.

No Frames - do not use frames.

Image Maps – do not use image maps unless you know the device supports them effectively.


4. Be cautious of device limitations

When choosing to use a particular web technology, consider that mobile devices vary greatly in capability.

Cookies – do not rely on cookies being available.

Objects or Script – do not rely on embedded objects or script.

Tables Support – do not use tables unless the device is known to support them.

Tables Alternatives – where possible, use an alternative to tabular presentation.

Style Sheets Support – Organise documents so that, if necessary, they may be read without style sheets.

Fonts – do not rely on support of font related styling.

Use of Colours – Ensure that information conveyed with colour is also available without colour.


5. Optimize navigation

Simple navigation and typing become critical when using a small screen and keyboard, and limited bandwidth.

Navbar – provide only minimal navigation at the top of the page.

Navigation – provide consistent navigation mechanisms.

Link Target ID – cleary identify the target of each link.

Link Target Format – Note the target file’s format unless you know the device supports it.

Access Keys – assign access keys to links in navigational menus and frequently accessed functionality.

URIs – keep the URIs of site entry points short.

Balance – take into account the trade-off between having too many links on a page and asking the user to follow too many links to reach what they are looking for.


6. Check graphics & colours

Images, colours and style brighten content, but require care due to inconsistent support for some formats low-contrast screens.

Images Resizing – resize images at the server, if they have an intrinsic size.

Large Graphics – do not use images that cannot be rendered by the device. Avoid large or high resolution images except where critical information would otherwise be lost.

Images Specify Size – specify the size of images in markup, if they have an intrinsic size.

No Text Alternative – provide a text equivalent for every non-text element.

Colour Contrast – ensure that foreground and background colour combinations provide sufficient contrast.

Background Image Readability – when using background images, make sure that content remains readable on the device.

Measures – do not use pixel measures and do not use absolute units in markup language attribute values and style sheet property values.


7. Keep it small

Smaller sites make us
ers happier by costing less in time and money.

Minimise – use terse, efficient markup.

Page Size Limit – ensure that the overall size of page is appropriate to the memory limitations of the device.

Style Sheet Size – keep style sheets small.

Scrolling – limit scrolling to one direction, unless secondary scrolling cannot be avoided.


8. Use the network sparingly

Web protocol features can help improve the user experience by reducing the impact of network bottlenecks and latencies.

Auto refresh - do not create periodically auto-refreshing pages, unless you have informed the user and provided a means of stopping it.

Redirection - do not use markup to redirect pages automatically. Instead, configure the server to perform redirects by means of HTTP 3xx codes.

External Resources - keep the number of externally linked resources to a minimum.

Caching – provide caching information in HTTP responses.


9. Help & guide user input

Keyboards and other input methods on mobile devices can be tedious to use, so effective designs minimize the need for them.

Minimise Keystrokes – keept the number of keystrokes to a minimum.

Avoid Free Text – avoid free text entry in forms, where possible.

Provide Defaults – provide pre-selected default values where possible.

Default Input Mode – Specify a default text entry mode, language and/or input format, if the target device is known to support it.

Tab Order – Create a logical order through links, form controls and objects.

Control Labelling – label all form controls appropriately and explicitly associate labels with form controls.

Control Position – position labels so they lay out properly in relation to the form control to which they refer.


10. Think of users on the go

Web users on the go want compact information when time is short and distractions many.

Page Title – provide a short but descriptive page title for every page.

Clarity – use clear and simple language.

Central Meaning – ensure that material that is central to the meaning of the page precedes material that is not.

Limited – limit content to what the user has requested.

Suitable – ensure that content is suitable for use in a mobile context.

Page Size Usable – devide pages into usable but limited size portions.

And reading through these, most of the list sounds equally applicable to overcome other accessibility issues. Wise advice, which isn’t always easy to follow!