Good evening once again, it’s great pleasure to be part of this panel!

I will be sharing the approach I take both at Yahoo! as well for the Government Projects I take up. Ground rule is that it’s always recommended that accessibility must be considered right at the beginning stage. There are two scenarios one is about making existing websites accessible and second is ensuring accessibility for all new websites. So at Yahoo!, what we do is for existing websites, we identify the issues across the site, document them and then schedule them in phase wise (we call it as sprints) to fix them. And for new websites, we partner with the product team right at the initial stage and eveluate them right at the mock stage, then support at the engineering stage, QA stage to ensure complete accessibility. Off late, we have created an accessibility automation tool to make the eveulation process simple.

While I look at the Government websites, what I would prefer to do is first use an automated tool such as WAVE Tool bar and if there are several issues, I would prepare a “Global findings report” that will enable their teams to address all the major issues. Once the major issues are addressed, I will take up detailed eveluation including manual testing. If automated tool shows less errors, I will do a quick manual test and if the page is bad, again I will prefer to submit global findings report and if I find the page better, then do a complete manual review.

Also, what I have observed is that it would be important for Design, SEO, Content and Accessibility teams to partner and work together so as to provide accurate support to the engineering team.

Lastly, I would suggest, do not rely just on automated tools. There can make you fool in scenarios like they can only check if there are text alternatives provided or not, but not if they are accurate.

• Provide inappropriate page titles or provide a common title for all the pages across the website something like the name of the organization without the respective page title
• Do not declare doctype of the document
• Do not define language of the document
• Do not provide text alternative to non text elements such as images, CAPTCHA, audio etc.
• Do not markup the headings in the documents
• Use table attributes for the layout purpose
• Do not mark up table summary, table headers
• Do not mark up associated labels for form fields using “for” and “id” attributes
• Do not provide site map to the website
• Do not use accessibility techniques while using Java script, Flash etc.

Best reading…

• Recommended list of DocTypes
• WAI Quick Tips to make Accessible Websites
• Creating Accessible Forms

1. Download NVDA Screen reader and install on your Microsoft Windows machine
2. Open your web browser perhaps Mozilla Firefox and visit the APSRTC‘s New Registration Form and you should see a beautiful form like below.

   

3. Press “F” key on your keyboard to reach to the first form field and then navigate the form using “tab” key; ideally you should hear something like “Username:edit, Password: password edit, Confirm password: password edit, Personal information, Firstname:edit” and so on. But you will hear something like “Table with 16 rows and 2 columns, row two, column two edit” and so on… and here is how this form looks on a text browser:
   

Now, let’s see what are the issues with above form. Firstly, screen reader is reading number of rows and columns, since the APSRT did not use CSS to control the layout of the form but have used <table> attributes to control the layout. Well, screen readers has the capability to turn off reading the layout tables but some users may not be aware of this option. Also, it is not recommended to use the table attributes to control the layout.

Second problem is that screen reader is unable to read the labels of the form since associated label “for” and “id” attributes are missing. Besides screen readers and text browsers, even search engines treat those form fields with no labels. Here are some ground rules to make accessible forms.

• Provide necessary instructions before the form states
• Do not indicate mandatory fields in form of color alone
• If a form field is a required field, inform the same to the user along with form label
• Provide associate labels to the form fields
• Use appropriate “fieldset” and “legend” attributes for check boxes and radio buttons
• If you opt to use image button, remember to provide alternate text
• If the form is dynamic, use ARIA labels, roles and states as appropriate

Related links:

• Creating Accessible forms – a WebAIM article
• Button Control: Using the Button ARIA Plug-in
• WAI – ARIA Live regions
• Easy Tip #2: aria-labelledby and aria-describedby

• Is the link “Skip to main content” exist? Although, there are several other ways to achieve quick navigation by providing heading mark-up, aria land marks, it’s still easier to hit on one link to reach the main content.
• Does the website provides any accessibility options, such as “Color options” “Font re-size option” etc? This would be good, if your target audience have learning difficulties or new to internet users, else, a help page with an article how one could use the existing accessibility options within the browsers would be helpful.
• Does all the informative images have appropriate alternate text?
• Does decorative images has given empty alt text i.e. alt=”"?
• Does the web page has appropriate heading structure?
• Does the website has a site map?
• Is acronyms provided with appropriate information?
• Does all the form fields have associated labels?
• Does the website uses Frames, if so, appropriate titles provided to frames?
• Is all the functionality of the web page available via keyboard?
• Does all the links have descriptive screen text?
• If an audio content is present, is there a synchronized captions or a text transcript available?
• If CAPTCHA is present, is it accessible to screen reader users and to Braille Display users? if not, is there an alternative method provided such as Audio CAPTCHA or logical questions based captcha
• Is semantic mark-up is used to designate headings and lists
• Are Table columns and rows have associated headers using “th” tags?
• Does tables have descriptive table summary and caption?
• Is structure of the web page is logical and meaningful?
• Color alone is not used to convey the information
• Is foreground and background color has enough contrast?
• Is there a pause / stop functionality for moving, blinking or scrolling content?
• The content and functionality should not have time limits, if necessary, user should be allowed to extend the time as per their choice. If the authentication expires, user should be able to re-authenticate and continue the activity without losing any data
• Page has appropriate and descriptive page title
• The language of the web page is identified using the HTML tag “lang” attribute

Disclaimer: Links on this post are verified on the date of this post. We are not responsible if the links get broken at a later date. If you notice the same, we appreciate, if you send us a note and alert us to update on the post.

• Yahoo! Accessibility Help
• Accessibility at Microsoft
• AOL Accessibility Help
• Adobe Accessibility
• Accessibility at Google
• FAQ – Oracle Accessibility Program
• Accessibility Word Press Codex
• Mozilla Accessibility Project
• Apple Accessibility
• Facebook Help Centre – Accessibility and Assistive Technologies
• IBM Accessibility

Before you get started, you need to make sure you have the right setup. You need …

1. The MathPlayer plugin . You can download this freely from
   http://www.dessci.com/en/products/mathplayer/download.htm?src=mplogo 
2. Internet Explorer 5.0 or above
3. Of course, you need your screen reader . ( We have tested it with JAWS 10 and 11 )

Now that you know what you need, here are the steps to set it up.

1. Download and install MathPlayer plugin on your machine for the math symbols to show up.
   (http://www.dessci.com/en/products/mathplayer/download.htm?src=mplogo)
2. Close the Internet explorer and reopen the file.
3. Use the normal JAWS navigation keys for Internet Explorer. You should now be able to read the math notations and formulae.

Visit our Samples here.

Thank you for visiting us; we extend a warm Welcome! LearnAccessibility is an initiative to create awareness about accessibility with primary focus to World Wide Web.

We endeavor to post wide range of articles with examples, additional reading links and as as simple as possible.

If you care for accessibility and wish to contribute to this portal, feel free to send your articles to info@learnaccessibility.org