Web Accessibility in the Corporate World

The Challenge

One of the biggest misconception in Web Accessibility today is that it is simple and straightforward and the guidelines should be sufficient to help us make Accessible web pages and user interfaces. Who needs expert advice when we have the guidelines already written, right? Well …

In an ideal world, our web content would be simple enough to be accessible but that is not the reality. The reality is that we have to make web pages accessible in conjunction with other efforts:

  1. Must be Responsive/Adaptive
  2. Must degrade gracefully
  3. Templates must be flexible enough to fit different scenarios
  4. Must be compatible with all major browsers and versions
  5. Must be compatible with all major assistive technologies and versions
  6. Semantics
  7. Etc.

To make matters worse, we also have editorial, legal, business challenges AND we have to make it work on whatever systems we are using. As we all know, every system would have its own limitations. All of these, plus we have to deal with co-workers who do not believe or understand the moral and ethical basis of Web Accessibility. This makes Accessibility one of the most under-estimated efforts in Web Development.

In addition, the guideline is like the law or any religious doctrines; there are varying interpretations and this causes a big debate on the A11Y approach. There are numerous articles regarding accessibility techniques yet developers and A11Y researchers can sometimes find themselves stuck trying to decide the correct approach even on what seemingly basic elements and A11Y principle.

Over-compliance and redundancy

These issues cause developers and A11Y researchers to struggle with choosing the best approach. There is always the fear of not being compliant or accessible enough which can result to over-compliance of the guideline and content redundancy.

Many of the issues can be solved by better editorial and design but there are many other things in play like legal and business constraints. In an ideal world, all will work together and will have enough time to analyze the best approach. However, in a fast-paced world of business and marketing, more often than not, there is hardly enough time to do this. A11Y developers and researchers then have to carry the burden of making everything work which results to developers/researchers slapping unnecessary ARIA tags and visuallyhidden texts everywhere.

Avoiding content redundancy

General Rule of thumb: A web page is a single document and should be treated as such.

Many of us fall into the pit of trying to cram everything in the headings, table captions and link texts for fear of not providing enough context to the point that we are forgetting that a web page is a single document with many sections and supporting information. No one ever reads a portion of a page and expect to get the full context just based on that portion. This is true for all users. Sometimes the problem is we over-complicate some A11Y issues.

In the example below, For fear of not providing enough context in the heading, the A11Y developer may add a visually hidden text. This is wrong because the paragraph below it already provides context.

<h2>Related WCAG 2.0 resources <span class="visuallyhidden">that provides
best-practice guidance on implementing accessibility in different
situations.</span></h2>

<p>These tutorials provide best-practice guidance on implementing
accessibility in different situations. This page combined the following
WCAG 2.0 success criteria and techniques from different conformance
levels:</p>

Headings do not need full context. Think of them as either navigational elements or list of topics seen in the Table of Contents.

If you are having difficulty identifying if it is a heading or a tagline/paragraph, ask yourself: Would I put this in the list of topics or subtopics if I were to make a table of contents?

Headings communicate the organization of the content on the page. Web browsers, plug-ins, and assistive technologies can use them to provide in-page navigation. (Source: W3C WAI Web Accessibility Tutorials – Headings)

This general rule of thumb also applies to table captions, link text, and other elements. For as long as you have enough supporting content, cramming content in the captions and link texts is not necessary.

Miracle workers

A11Y developers and advocates are oftentimes expected to provide solutions as though we are miracle workers. We are faced with scenarios like; if you do technique A, the user experience for group B will not be optimal but if you do technique B, the user experience for group A will not be optimal. So what is the best approach when there is not one solution that will fit all?

Rule of Thumb: Accessibility is like clothing sizes.

Like clothing sizes, there is no one size that fits all but you can make standard sizes for the widest amount of users. A medium size may be too small and a large may be too big but at least there are options and you will not have to go naked. The same way with accessibility, some techniques may not be the best experience for some groups but at least they can access the content.

And access is the whole point of the effort.

So, no need to beat yourself up if you cannot come up with a perfect solution that fits all. With all the challenges that we have to deal with to provide access to information for all people – we are still miracle workers. 🙂

Donna Maddox

About Donna Maddox

Donna Maddox is Senior Developer and CMS Architect for a major airline. Originally from the Philippines, she transplanted to Chicago. Aside from web development / programming, she's into Philosophy, Psychology, Ancient History, Science and Technology. A humanist in ideology but she likes animals more than she likes people.

One comment on “Web Accessibility in the Corporate World”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>