Skip to main content

Home/ Web Accessibility/ Group items tagged links

Rss Feed Group items tagged

Sandra Earl

The Dutch accessibility law is awesome | 456 Berea Street - 0 views

  • New Dutch accessibility law.
  • A few highlights of what is required: separate structure from presentation do not use deprecated markup when creating a new website, use a Strict doctype use progressive enhancement create semantic class and id values use the W3C DOM when scripting script-only links must be generated by JavaScript do not use the alt attribute to create tooltips
Sandra Earl

BBC Internet Blog - 0 views

  • We considered a few approaches, but decided to grow our new widget out of Adobe Flex and Adobe AIR. This is firstly because these tools met our requirements to work cross-platform and deliver the desktop experience we wanted, and also because they linked up with in-house skills in the team which manages them, making them simpler to manage.
  • BBC Future Media & Technology's pilot widget application BBC LiveUpdate uses the Adobe AIR runtime, which is dependent on users downloading and installing a plugin to their desktop, but which unfortunately does not currently support screenreaders (or other software which relies on the Microsoft Active Accessibility layer for assistive technologies). We're working with Adobe to make tools built with AIR more accessible than current products wherever possible and are committed to delivering accessible services. As this is a beta product, there are also other limitations in how much we have been able to establish accessibility support in the following areas:Colour contrast cannot be alteredText size cannot be alteredLacks consistent alt textLacks Title attributesIs not entirely tabbable.
Sandra Earl

Designing for Dyslexics: Part 3 of 3 - Accessites.org - 0 views

  • Shorter line lengths and narrower text columns make reading easier.
  • Consider setting a percentage width for text areas and set the margins to “0 auto” via CSS. The page side margins will then increase proportionately on wider screens.
  • Most browsers have a default line-height of around 1em. This normally results in closely packed lines of text. Increasing the line-height to around 1.3em immediately makes longer lines of text easier to read. Likewise, ensure that paragraphs are visibly separated. Don’t be afraid of white space. Use it to enhance readability.
  • ...16 more annotations...
  • percentages or ems.
  • If possible, use a sans-serif font. The decorative “hooks” on the main strokes of serif letters may create additional problems for dyslexic users.
  • If you have to use a corporate serif font, consider reducing the letter-spacing slightly so that the letters within a word lie closer together but increasing the word-spacing to create a slightly larger distance between individual words.
  • uneven word spacing disrupts that pattern recognition.
  • Unjustified text, although less attractive at first glance. is far easier to read.
  • When italic fonts are used on a web page, the individual letters can have a slightly jagged line compared to a non-italic font. This “pixelation,” coupled with their “lean to the left” makes them hard for a dyslexic person to read. The effect is compounded if the text is also small.
  • Use italics sparingly and consider bold text for important words. They’ll be far easier to read.
  • Photographs, charts and icons can convey a great deal of information regarding the topic of a page. Graphics can break the page up into smaller chunks. They can also provide visual memory aids and support comprehension for dyslexics.
  • Dyslexics often have poor organisational skills. Lists can help them by organising information into small, logical chunks.
  • Dyslexics tend to have poor information processing skills. So it is relatively easy to overload them by literally providing too much information on one page.
  • Within a page, use headings to sub-divide the page logically and visually. Adding coloured heading backgrounds or borders will act as further support.
  • Consider breaking complex pages down into two or three smaller pages.
  • Keep site navigation simple and logical. Make sure that the Home page is easily reachable from any part of the site. Try not to “hide” this important link in a logo.
  • break long sentences down into two or more shorter sentences
  • Many designers do not realise that some screen reader users can see perfectly well. It is not uncommon for dyslexics to use screen readers to support their reading. This may create problems where text has been positioned off screen.
  • If you do make use of off screen positioning, try to do so sympathetically. Consider the viewpoint of those who can both hear the screen reader and see the page. Ask yourself if you’re potentially creating confusion.
Vernon Fowler

WebAIM: Usable and Accessible Form Validation and Error Recovery - 0 views

  • Errors on top
  • As one would guess, the "Errors on top" approach causes the error message to appear before the form. When presented, focus should generally be set directly to this error message. This allows screen reader and keyboard users to immediately access the error message without having to find it amongst the rest of the page contents. The message should also be visually apparent. Focus can be set to the message with client-side scripting using JavaScript focus() or similar, or the server-generated page can include an anchor name in the URI (e.g., http://myserver.com/form.php#errormessage) which will set focus directly to a named anchor or element id located at the beginning of the feedback message.
  • also helpful to inform the user as to the number of errors that were detected
  • ...2 more annotations...
  • provide a link within the error message that will set focus to the appropriate form control
  • Regardless of the mechanism used to identify and recover from form errors, aria-invalid="true" should generally be set on each invalid form control. This attribute causes screen readers to identify the control as being "invalid" or in need of attention.
Vernon Fowler

Understanding screen reader interaction modes - Tink - 0 views

  • the screen reader intercepts most keypresses before they reach the browser, triggering an interaction with the virtual document instead
  • up/down keys move focus to the previous/next line instead of scrolling the page
  • space key to select a checkbox
  • ...3 more annotations...
  • enter key is used to activate a link
  • Not all keypresses are captured by the screen reader however. When the tab key is pressed it is automatically passed through to the browser where it causes keyboard focus to move to the next piece of interactive content
  • Although this mode switching may seem unintuitive to someone unused to Windows screen readers, it works well in practice and most screen reader users are unaware of what’s happening “under the hood”.
« First ‹ Previous 41 - 45 of 45
Showing 20 items per page