Koha Test Wiki MW Canasta on Koha Portainer

Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.

For the current Koha Wiki, visit https://wiki.koha-community.org .

Category talk:Development

From Koha Test Wiki MW Canasta on Koha Portainer
Jump to navigation Jump to search

What is Accessibility?

Making your website available to as many people as possible

  • Blind
  • Sight impaired (long sighted, short sighted, colour blind, cataracts, etc.)
  • Deaf
  • Motion impaired
  • Mentally impaired

The solutions to these disabilities are not difficult, however they do require forethought. For example:

Disability User Issue Website Issue Impact Solution
poor eyesight The user can't read small text Using fixed size fonts User cannot make text larger in IE Use relative size fonts
blind The user can't see new popup windows Using popups User cannot use the back button in their browser or know they are in a popup Don't use popups (unless as a last resort)

There are many more examples.

Basic Tips

  • Give your images meaningful ALT text (No ALT text and the URL is read out)
    • If the image adds to the content, describe it properly
    • If the image is just to be pretty, have alt="". (Screen readers will ignore the image)
  • Use skip links (Skip to Content, Skip to Navigation, etc.)
    • Hide them with CSS and your regular users will never know
  • Don't rely on Javascript
  • Have a decent amount of contrast in your styles
  • Have code flow logically from top to bottom
    • Header
    • Navigation
    • Content
    • Footer
  • Use HTML headings. One H1 per page then logical H2 through to H6. Don't use headings for things that aren't headings.
  • Use UL's and OL's for lists (including navigation)
  • Validate your code
  • Hyperlinks should have full context. "Here are some photos of my trip to Bucklame" vs. "Here are some photos of my trip to Bucklame"
    • Screen readers are able to grab just the links from a page
  • Ensure that all functionality is accessible via the keyboard

WCAG 2.0 Cheat Sheet

The Web Content Accessibility Guidelines 2.0 (WCAG 2.0) is a document that discusses how to make online content accessible to people with disabilities and non-disabled users. Here is a cheat sheet containing the most important techniques included in WCAG 2.0.

Principle 1: Perceivable

  • Non-text content should have text equivalents
    • Images should have text descriptions
    • Videos should have captions
    • Audio should have text transcripts
  • Use appropriate semantic elements and ensure that structural relationships presented visually are available through the markup
    • Headings should use HTML headings
    • Lists should use HTML lists
  • Ensure that the reading sequence presented visually is available through the markup
  • Avoid relying on sensory characteristics such as shape or visual location when providing instructions
  • Colour contrast ratios should be sufficient to support easy reading
  • Avoid using colour as the sole means of conveying information
  • Provide a means to play/pause/stop audio in a page
  • Ensure that the page remains usable when text is resized to 200%

Principle 2: Operable

  • All functionality should be available via the keyboard
  • During sessions where there is a time limit, provide a means to extend the time
  • Do not design content in a way that is known to cause seizures (content that flashes more than three times per second)
  • Provide a means to bypass repetitive blocks of content
  • Page titles should describe the page's content or purpose, and should preferably be unique
  • Keyboard users should be able to navigate the page sequentially and the page should retain its meaning
  • Link text should describe the link's purpose
  • Headings and labels should describe their topic and purpose
  • Keyboard focus should always be visibly indicated

Principle 3: Understandable

  • Define the language of the page
  • If parts of a page are in a different language, that language is identified
  • Try to make text easy to read and understand
  • Ensure that when a page element receives or loses focus, it does not change the context of the page, such as loading a new page
  • Ensure that when an interactive element receives input, it does not change the context of the page unless the user has been warned
  • Ensure that navigational structures repeated on multiple pages occur in the same order on the page each time they appear
  • Ensure that elements with the same functionality are consistently identified
  • Enable users to easily determine errors they have made
  • Provide clear labels and instructions wherever user input is required
  • If there is an error in user input, provide suggestions on how to correct it
  • For legal or financial forms that modify user data in a database, allow the user to reverse any changes or to correct any errors prior to submission

Principle 4: Robust

  • Ensure that HTML markup is used according to specification
  • Ensure that for all custom-built components, the components' state, properties and values are provided in the markup

Initiatives

Tools

Automated tools are not a sufficient test of accessibility, however they are a starting point. The best testing is with real users.

Retrieved from "https://wiki.test.koha-community.org/w/index.php?title=Category_talk:Development&oldid=9147"