Monday, October 14, 2013

Building an Accessible CMS Site

Notes from the September 25, 2013 AccessibleWeb@U meeting

  • How a CMS Works
    • Content management system (CMS) engine, such as Drupal or WordPress
    • A database, often MySQL
    • A theme to structure and present content
    • Plug-ins to add functionality
  • Accessibility Principles
    • Perceivable
    • Operable
    • Understandable
    • Robust
    • From Web Content Accessibility Guidelines (WCAG) 2.0 http://www.w3.org/TR/WCAG20/
  • Goals
    • Create an inclusive University
    • Building a site that works with assistive technologies
    • NVDA Screen Reader - http://www.nvaccess.org/
    • FireVox - http://firevox.clcworld.net/
    • VoiceOver - http://www.apple.com/accessibility/osx/voiceover/
    • Building a site that is intelligible to people using assistive technologies
  • Methods for building accessible CMS sites
    • Adhere to standards
    • Use semantic elements
    • Follow WCAG 2.0
    • Apply Accessible Rich Internet Applications (ARIA) attributes
    • Use ECMA Standard Scripting
    • Use Progressive enhancement methods in scripting
  • Page Design Access Blockers - Addressed by theme designer
    • Contrast and luminosity
    • Color issues
    • Font legibility
    • Reading order
    • Scalability (user-scalable=yes)
  • Content Access Blockers - Addressed by the people who enter content into the pages
    • No page <title/>
    • No heading elements <h1/>…<h6/>
    • No link element text or title=“” attributes
    • No form element label elements
    • No caption elements and <table/> summary attributes
    • No scope and id attributes to relate column and row headers to data
    • No useful alt text for images, or are missing the alt attributes altogether
    • No captions for videos
  • CMSs, Out of the Box, Start With Good Accessibility
    • WordPress http://make.wordpress.org/themes/guidelines/guidelines-accessibility/
    • Drupal https://drupal.org/about/accessibility
    • Understand what they have done
    • Don’t mess it up
  • Themes
    • Pre-built set of code that defines page layout, colors, functionality, fonts and font sizes, and navigation
    • Many are built on frameworks such as Bootstrap, which provide libraries of code
  • Examples of Accessible Themes
    • Blaskan – http://wordpress.org/themes/blaskan
    • Badeyes Skeleton – http://www.badeyes.com/services/
    • Ambrosia – http://wordpress.org/extend/themes/ambrosia
    • Scrapbook – http://wordpress.org/extend/themes/scrapbook
    • Twenty-Twelve Child Theme – http://daniemon.com/blog/accessible-wp-theme-twenty-twelve/
    • Examine them closely, perfection has not yet been achieved
  • Frameworks
    • Themes are generally built on existing frameworks, which may or may not have been created with accessibility in mind
    • Example frameworks:
      • Bootstrap - http://getbootstrap.com/
      • Skeleton Boilerplate - http://www.getskeleton.com/
      • Whiteboard - http://whiteboardframework.com/
    • Most frameworks are created without much consideration of accessibility
      • Non-semantic coding
      • Forms without labels
  • Give Content Maintainers an Environment That Lets The Do The Right Thing
    • Carleton CMS Training video on accessibility considerations when entering content in the Carleton WordPress site - http://www.youtube.com/watch?v=H5N57Kwjx9s
  • Resources
    • Accessibility With WordPress - http://www.slideshare.net/joedolson/accessibility-with-wordpress
    • Accessibility, WordPress Codex - http://codex.wordpress.org/Accessibility
    • 25 Ways to Make Your WordPress Site More Accessible -  http://wpmu.org/25-ways-to-make-your-wordpress-website-more-accessible/
    • WP Accessibility Plug-in http://wordpress.org/plugins/wp-accessibility/
Posted by at 1 comment:

Friday, August 23, 2013

ARIA Basics

AccessibleWeb@U - August 22, 2013
  • Announcements
    • ACM SIGACCESS ASSETS 2013 Conference on Computers and Accessibility, October 21-23 in Bellevue, WA
      • http://www.sigaccess.org/assets13/
      • This conference has top-notch speakers, including UW's Richard Ladner, and it is the first time since 2006 that it has been held on the West coast
    • Accessibility Camp Seattle Oct 19-20, in Seattle Public Library's downtown Central Library
      • http://accessibilitycampseattle.org/blog/
  • ARIA Basics
    • Rick Ells, presenter
      • UW-IT Web Guy rells@uw.edu
    • Semantic Web
      • Communication is not just letters clumped into words. The words are assembled into sentences, with particular words playing roles such as subject, verb, and object.
      • Structure and role are part of communication
      • ARIA is a way to declare the roles of elements on a page.
    • What is ARIA
      • Accessible Rich Internet Applications (ARIA)
      • Associating meta information to page elements that helps assistive technologies “understand” and interact with the page
      • ARIA landmarks are added to HTML/XHTML/HTML5 as element attributes
      • ARIA landmarks do not change the elements, they just associate information with them
    • Disadvantage of ARIA
      • ARIA is not part of the specifications for HTML 4.01 or XHTML.
        • Such pages with ARIA attributes will not validate
        • The ARIA attributes will be flagged as non-complying
      • Validation is important, but advantages of adding ARIA outweigh the disadvantage of seeing error messages
    • Using ARIA
      • To enhance accessibility of your pages with ARIA
        • Build standards-based validated pages
          • Use semantic types correctly
          • Use headings hierarchically
          • Provide alt texts and labels
        • lApply appropriate ARIA landmarks
    • How ARIA Landmarks Work
      • Video
        • http://www.webmonkey.com/2013/02/video-how-arias-landmark-roles-work/
    • Types of ARIA Landmarks
      • Banner role
      • Contentinfo role
      • Main role
      • Complementary role
      • Form role
      • Search role
      • Navigation role
      • Information in this section is from North Carolina State University http://accessibility.oit.ncsu.edu/training/aria/
    • Banner Landmark
      • The ARIA role "banner" is used to indicate mostly site-oriented content rather than page specific content.
      • Add the attribute role="banner" to the encompassing <div>.
      • Add the attribute aria-labelledby="bannerHeading" to the encompassing <div> to explicitly say what the heading is for this section.
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#banner
    • Contentinfo Landmark
      • The ARIA role "contentinfo" indicates a region that contains information about the parent document. It often contains information like copyright and privacy statements.
      • Add the attribute role="contentinfo" to the encompassing <div>.
      • You should use the role "contentinfo" only once per page.
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#contentinfo
    • Main Content Landmark
      • The ARIA role "main" is used to indicate the content that relates directly to the central topic of the document.
      • Add the attribute role="main" to the encompassing <div>.
      • Add the attribute aria-labelledby="mainContentLabel" to the encompassing <div> to explicitly say what the heading is for this section.
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#main
    • Complementary Landmark
      • The ARIA role "complementary" is used to indicate content that is complementary to the main content, yet has meaning when separated from the main content.
      • Add the attribute role="complementary" to the encompassing <div>.
      • Add the attribute aria-labelledby="validationLabel" to the encompassing <div> to explicitly say what the heading is for this section.
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#complementary
    • Form Landmark
      • The ARIA role "form" is used to indicate a section that contains a form.
      • Add the attribute role="form" to the encompassing <div>.
      • Add the attribute aria-labelledby="newsletterLabel" to the encompassing <div> to explicitly say what the heading is for this section.
      • Using the role="form" still requires you to use the <form> tag and accompanying <label> and <input> tags.
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#form
    • Search Landmark
      • The ARIA role "search" is used to define a region where search functionality is located. The role "search" is a specialized version of "form" so you do not need to label this section with the role of "form."
      • Add the attribute role="search" to the encompassing <div>.
      • Add the attribute aria-labelledby="searchLabel" to the encompassing <div> to explicitly say what the heading is for this section.
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#search
    • Site Navigation Landmark
      • The ARIA role "navigation" is used to indicate a collection of links to navigate the document or related documents.
      • Add the attribute role="navigation" to the encompassing <div>.
      • Add the attribute aria-label="Site Navigation" to add a descriptive label to this section
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#navigation
    • Application Landmark
      • Declares a region as a web application, as opposed to a web document
      • Tells assistive technologies to switch to an application browsing mode and pass keyboard events directly through to the web application
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#application
    • The ARIA Specification has many more roles
      • http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#role_definitions
    • Looking At ARIA Markup
      • The Web Developer Toolbar for Chrome and FireFox has a Display ARIA Roles item in its Information menu.
        • http://chrispederick.com/work/web-developer/
      • Firebug add-on for FireFox makes it easy to hop into the code of a page and see what ARIA attributes it contains
        • https://addons.mozilla.org/en-us/firefox/addon/firebug/
    • Examples of Using ARIA
      • OpenAjax Accessibility Task Force examples
        • http://oaa-accessibility.org/examples/
Posted by at No comments:

Friday, July 26, 2013

Colors & Contrast

Notes from the July 25 meeting of the AccessibleWeb@U interest group


  • Presenter - Rick Ells UW-IT
  • Vision
    • Normal - Has red, green, and blue sensors
    • Protanopia – Red/green color blindness, less sensitive to red light
    • Deuteranopia – Red/green color blindness, less sensitive to green light
    • Tritanopia – Blue/ yellow color blindness, confuse blue with green and yellow with light violet
    • Cataracts
    • http://www.color-blindness.com
  • Color Combinations
    • Use orange only for large text or highlight
    • Avoid red on green or green red
    • Avoid using red and green to convey information, such as red text is a warning, green text is a recommendation
    • Avoid putting bright colors at the opposite end of the spectrum together
    • Avoid putting text on textured backgrounds
  • Contrast and Luminosity
    • Contrast is the difference in brighness (luminosity) between two colors, such as between the color of text and the color of the background
      • More contrast is needed for smaller text
      • 4.5:1 for content text (Level AA)
      • 3:1 for large text (Level AA)
  • Guidelines
    • 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following:
      • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
      • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
      • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
  • Example Site
    • http://staff.washington.edu/rells/accessibility/contrast/low.htm
    • Evaluate the example site using the Colour Contrast Analyzer - http://www.visionaustralia.org/business-and-professionals/digital-access/resources/tools-to-download/colour-contrast-analyser-2-2-for-web-pages
  • Maintaining Hue
    • When you need to darken or lighten a hue, maintain the same relative ratios between the red, green and blue values.
    • Example: The following are the same hue, but different luminosities
      • RGB 50, 75, 100 - darkest
      • RGB 75, 112, 150 - medium
      • RGB 100, 150, 200 - lightest
  • Tools
    • Contrast-A http:// www.dasplankton.de/ContrastA/
    • Color Oracle - http://colororacle.org
    • WebAim Contrast Checker - http://webaim.org/ resources/contrastchecker/
    • ColorHexa - http://www.colorhexa.com
    • Colour Contrast Analyzer - http://www.visionaustralia.org/business-and-professionals/digital-access/resources/tools-to-download/colour-contrast-analyser-2-2-for-web-pages
Posted by at No comments:

Monday, January 28, 2013

Survey and Planning

AccessibleWeb@U Meeting Notes Jan 24, 2013

  • Survey results
    • 22 people responded, most were webmasters or people maintaining content
    • Ranking by sum of "Strong interest" and "Very strong interest"
      1. 75% - Creating accessible websites: Instructions, tips, and resources
      2. 64% - Accessible UW templates and themes for WordPress and Drupal
      3. 59% - Accessible plug-ins and modules for WordPress and Drupal
      4. 53% - Authoring accessible documents in Word, PDF, and other formats: Instructions, tips, and resources
      5. 50% - Disability-related resources and services available at the UW
      6. 45% - Getting help with accessible technology problems and issues
      7. 41% - Captioning video: Instruction, tips, and resources
      8. 41% - Legal requirements and policies related to technology accessibility at the UW
      9. 28% - Opportunities for getting involved with efforts to improved accessibility of technology at the UW
      10. 27% - Procuring accessible technology products
    • In comments, respondents suggested more task oriented content, better structure, shorter and clearer text
    • Summary of what the results seem to mean
      • Basics of how to create accessible websites is most important
      • Strong interest in prebuilt environments (CMSs and plug-ins) that have accessibility built-in
      • Moderate interest in authoring accessible documents
      • Site needs to more engaging, better organized, and task oriented
  • Reviewing the website (http://uw.edu/accessibility/)
    • About the site as a whole
      • Could there be a site search for just this site?
        • An alternative could be a site map
        • If site is in its own WordPress instance, it would have a site-specific search
      • Could there be an accessibility news blog?
        • Important to prepare items carefully and get review
          • Consistent quality and relevance is important for giving visitors a reason to come back
          • Should be a steady flow of items, at least a couple a week
        • Items should be written with consistent role, voice, and style
        • If we can find a news source we respect, we could simply put its news feed on the site
          • WebAIM (http://webaim.org/) might be a source
        • We could also link to forums where good discussions are occuring
        • A blog could be used to foster discussions on topics
      • How could we offer training on accessible design?
        • WebAIM offers training in Utah (http://webaim.org/services/training/). They sometimes travel. Could we find money for a workshop here at the UW?
        • UW-IT Learning and Scholarly Technologies (LST) offers workshops (http://www.washington.edu/lst/workshops). Could LST host an accessible design workshop?
        • Could we develop training videos, perhaps using Tegrity?
          • Developing a polished training video can be time consuming.
      • Could the site have demonstrations of accessible and inaccessible designs?
        • Demonstrating lack of accessibility might best be done with videos of people trying to use the site
      • Could the site have explanations and videos of converting an inaccessible site to become accessible?
    • Current topics
      • Historical Highlights
        • Should be moved to the bottom; interesting but not what people come for most of the time
      • Policies & Standards
        • We have many good quotes from the UW President in the "IT Accessibility: What Campus Leaders Have to Say" video (http://www.washington.edu/doit/Video/index.php?vid=55), which is linked to from the home page
        • Using those quotes, we could convey that the UW has chosen a shared intention of being accessible; would help to localize; we are not just doing this because external entities have ordered us to.
      • Web Accessibility
        • Move the "why be accessible" stuff down on the page
        • Put the "getting started" or "is my site accessible" stuff at the top
        • Checklists for evaluation of accessibility and step-by-step procedures would be helpful
  • Discussion
    • We should build a list of possible things we could do and then sort them out by priority and timing
    • One key role for the site might be to help people connect with mentors who could be there as they learn accessible design
      • Who would be the mentors?
    • Simply building up a network of practitioners, facilitating their cooperation and sharing would be valuable
    • The survey showed strong interest in pre-built solutions such as accessible themes and plugins
      • How do we know which themes and plugins to point people to?
    • Is it time to host another Capacity Building Institute?
      • We hosted a CBI in 2008 (http://www.washington.edu/accessibility/cbi2008.html)
      • Defining the problem well is an essential step
      • In a CBI, speakers give short presentations and then work with the audience to develop solutions
      • Everyone is involved in the discussion through the day
      • Everyone is assumed to be part of the problem and and important member of the community that will develop solutions
    • Connecting with the Web developers is challenging
      • Often working on tight deadlines
      • Generally work from their own toolset of skills, favorite code libraries, javascript libraries, code management methods, and project management methods, all of which may or may not have been developed to support accessible design
Posted by at No comments:
Subscribe to: Posts (Atom)