Archive for the ‘Web Accessibility’ Category

If the articles presented below don't fully cover the question, https://bestwritingservice.com/ - one of the representatives of best writing services will answer all the questions.

Methodologies for Accessibility Eveluation

Published by WebAdmin on April 1st, 2011

Recently I was on a panel discussion organized by The Global Initiative for Inclusive ICTs (G3ICT), World Wide Web Consortium and The Centre for Internet and Society at 20th World Wide Web Conference and during the panel we have discussed the various methodologies for Accessibility Evaluation. It was a pleasure to share the panel with Shadi Abou-Zahra from W3C, Glenda Sims of Deque Systems Inc, Dr. Neeta Varma of National Informatics Centre (NIC) and the panel was moderated by Nirmita Narasimhan of Centre for Internet and Society. Here is the transcript of my thoughts.

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.

No Comments »
Posted in Web Accessibility

Common mistakes of that a web developers make

Published by WebAdmin on October 3rd, 2010

Most developers feel making a website accessible require an additional effort, time consuming and needs to write a lot of additional code; which is actually not very true. But yes, there are certain additional things to be done, but they are most times enhancements. Having said that, most of the efforts that require to make a website accessible are the best practices of HTML. Here, I will endeavor to illustrate some of the common mistakes that a web developer commits.

  • 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 External Website 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…

1 Comment »
Posted in Web Accessibility
Tags: , , , ,

Writing accessible HTML forms

Published by WebAdmin on August 8th, 2010

We fill a lot of forms on the web on daily basis – may it be for a bank transaction, booking of travel, shopping etc. Often we see forms looks very beautiful but in reality, most of them are not beautiful due to lack of associated labels. Oh! wait, we know, you are about to shown on us and say that you have never seen a form just with input elements and without text labels, you are right, but did you ever see a form with a text browser or with a screen reader. Here is an exercise for you before reading this article:

  1. Download NVDA External link 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.

    APSRTC New Registration form

  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:
    Text version of APSRTC Registration form

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:

1 Comment »
Posted in Web Accessibility
Tags: , , , , , ,

A quick Web Accessibility Checklist

Published by WebAdmin on July 29th, 2010

Often we hear people asking how can they check for a website for accessibility and what needs to be checked. Here is a quick checklist and hope this would be handy to someone!

  • 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
10 Comments »
Posted in Web Accessibility
Tags: ,

Top Accessibility resources

Published by WebAdmin on July 25th, 2010

Often, we look for accessibility pages of different organizations to know accessibility features of their respective products and services. Not always, it’s easy to invest time to search on internet. So I thought, let me start off listing accessibility links of different companies across the globe.

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.

No Comments »
Posted in Web Accessibility
Tags: , , , ,