ASP.NET Accessibility Top Ten

Here are my top ten tips for designing accessible ASP.NET sites. These are based on my understanding and opinion. If I am radically wrong about any of these, please feel free to correct me by leaving a comment.

Always set the display of validation controls to ‘dynamic’
In this way, screen readers ignore the text of the error message when there is no error.

Do not use image buttons
They are invisible to screen readers. Use a button with a background image instead.

Do not use AutoPostBack
They are impossible to navigate using a keyboard.

Do not use separator characters between links
Characters in breadcrumbs, footers, etc. are read out by screen readers. Use a span instead with a style instead. Or better still, use a bulleted list with a background image.

Display sets of results or links in a bulleted list
In a landing page or search results page, having each result marked up as a bullet makes it easier to navigate between results.

Insert hidden header text at the start of every navigation list
Screen reader users can navigate by headers and choose to skip the navigation lists.

Surround the individual digits in telephone numbers with span tags
Otherwise, the whole number will be read out as a single value.

Use hidden images with pagination and other non-descriptive hyperlinks
If pagination links are in the format: 1 | 2 | 3, a screen reader will read the links as ‘link 1’, ‘link 2’ and so on. So, insert a hidden image that has the alt text set to something more descriptive.

Include file sizes and types in hyperlink text
Unwittingly clicking a link to a file attachment can cause confusion.

Don’t bother using access keys
They are device-dependent, they can conflict with other shortcut keys and there is no standardisation as to what each key combination should do. Better to have clear navigation.

Accessible print-friendly web pages

There are times when you might want to render a page specifically for printing (rather than using CSS). For example you might want to include or exclude specific information on the printed page. When users view the print-friendly page, you might want to include some instructions at the top of the page, but not have these themselves print out. You might want to let users know they are viewing a print-friendly version and provide them with a link back to the on-screen view.

You can do this by first defining a “noprint” class:

    <style type="text/css">
        @media print
        {
            .noprint
            {
                display: none;
            }
        }
    </style>

You can then include your instructions in a DIV having this class.

Typically, the next action a user will take on viewing the page is to open the print dialogue box. We could attach a “window.print()” JavaScript action to the body’s onload event, or within a <script> tag somewhere in the body. However, having a dialogue box appear automatically is not particularly accessible as it changes the focus. The alternative is to insert a “print this page” link if the browser supports JavaScript. For non-JavaScript browsers, simply inform the user to use his or her browser’s print menu. This is demonstrated by the following HTML:

    <div class="noprint" style="background-color: #eeeeee;
border: solid 1px black; padding: 10px 10px 10px 10px;">
        <p>
            You are viewing a print-friendly version
 of a page.</p>
        <p>

            <script type="text/javascript">
                var str = "Print this page";
                document.write(
str.link("javascript:window.print()"));
            </script>

        </p>
        <noscript>
            <p>
                Please select print from your browser’s
menu to print the page</p>
        </noscript>
        <p>
            or <a href="/path/file.htm">
return to the normal on-screen view of the page
            </a>
        </p>
    </div>

Screen reader friendly phone numbers

When you display a telephone number on screen, screen readers read it out as a single number. The Fangs screen reader emulator (see http://sourceforge.net/projects/fangs) reads the number (01234) 567890 as “left paren six hundred sixty-eight right paren five hundred sixty-seven thousand eight hundred ninety”. The “six hundred sixty-eight” bit is particularly curious: the 01234 is being interpreted as an octal number.

By encasing each digit within a <span /> tag, the digits are read out individually. So, (01234) 567890 becomes “left paren zero one two three four right paren five six seven eight nine zero”.

I have written an XSLT template that takes a phone number and applies a <span /> to each digit:

  <xsl:template name="DisplayPhoneNumber">
    <xsl:param name="position" />
    <xsl:param name="phonenumber" />
    <xsl:variable name="digit"
select="substring($phonenumber, $position, 1)" />

    <xsl:choose>
      <xsl:when test="contains('012345678', $digit)">
        <span>
          <xsl:value-of select="$digit" />
        </span>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$digit" />
      </xsl:otherwise>
    </xsl:choose>

    <xsl:if test="$position &lt;
string-length($phonenumber)">
      <xsl:call-template name="DisplayPhoneNumber">
        <xsl:with-param name="position">
          <xsl:value-of select="$position+1" />
        </xsl:with-param>
        <xsl:with-param name="phonenumber"
select="$phonenumber" />
      </xsl:call-template>
    </xsl:if>
  </xsl:template>

To call the template, pass in the telephone number and prime the starting position using a value of 1:

      <xsl:call-template name="DisplayPhoneNumber">
        <xsl:with-param name="position" select="'1'" />
        <xsl:with-param name="phonenumber"
select="'(01234) 567890'" />
      </xsl:call-template>

If you’re using this within Sitecore, you can simply pass in a field value in the usual way:

      <xsl:call-template name="DisplayPhoneNumber">
        <xsl:with-param name="position" select="'1'" />
        <xsl:with-param name="phonenumber"
select="sc:fld('phone', .)" />
      </xsl:call-template>