This is a crosspost of http://dotgov.com. Author: Jim Thatcher

I am looking for a surprise. It would be so gratifying to open up a government web site, any government website, and be impressed with its accessibility. The New York City site isn’t that site. In fact, the accessibility of the New York City site is markedly similar to to what I reported here for the District of Columbia site. Please – can someone suggest a (non-federal) government site which shines for accessibility. We need a government site that sets the bar. There must be one out there!

In-page Navigation on the Residents Page

I decided to look at the Residents’ page of the New York City site because it is just a little simpler than the homepage.The issues are clearer. One of those issues is what I call “in-page navigation.” Below is a screen shot of the Residents page. The sections are pretty clearly defined and those sections have headings.

Sure there are headings on the page but they are not marked up as headings. In fact I found no headings markup on any NYC.gov page that I looked at.

For the Residents page (screen shot above) here is how I would mark up the headings:

• (h1) Residents (class="top_section_header")

  • (h2) HHC Diabetes Welcome Center (class="feature_header_large")

    • (h3) 21st Annual New York Cares Coat Drive (class="feature_header")

    • (h3) Other features

  • (h2) Search NYC.gov for

  • (h2) FEATURED EVENT (class="module_header")

  • (h2) 311 Online (class="module_header")

  • (h2) NY CITY MAP (class="module_header")

  • (h2) DID YOU KNOW (not visible in screen shot) (class="module_header")

If the site used headings markup as I have suggested here, a blind New York City resident using JAWS could survey the sections of the page (and all pages) with a few presses of the H key. The first H key jumps over the navigation area to land on the “main content” of the page.

It is amusing – well sort of amusing – to look at the the class names that developers assign to the text that we say should be marked up as headings. I have indicated those class names in the list of proposed headings above. As is the case here, it is very common to see class names that clearly indicate that the developer knew that these were headings – they knew they were headings but they did not use HTML headings markup for them.

Which text should be marked up as a heading – and at what level – is not set in stone. My suggestions here could be numbered differently. You might add an invisible h2 heading at the top of the links on the left, like (h2) Departments. The idea is that text which looks like heading text should usually be marked up as heading text, and you should be sure that the headings provide good access, i.e., convenient access, to the sections of the page.

Images on the Residents’ Page

There are about 130 images on the Resident’s page – and every one of those images has alt-text. Great! In fact there are very few and relatively minor errors with the quality of the alt-text.

The images down the center are active and each links to one of the feature stories. On the left is one example. The alt-text on the site is alt="DOT Logo" and that is the alt-text we have here which is fine for the inactive logo. But on the New York City Residents web page, this image is a link to an associated story about the availability of the Alternate Side of the Street Parking Calendar in different languages. This does not link to DOT, or DOT logo, it links to information about alternative side of the street parking (which is a huge deal it you live in New York City!). So I think the alt-text should be alt="ASP calendar available in different languages".

For each of the images down the center, the alt-text can be improved in a similar fashion.

Form Labels

Good work with the images, but the work on form controls is another question. The Residents page has quite a few form controls. At any time only a few are visible but as you interact with the NYC Map options on the right, different controls appear. There are about 21 controls associated with the Map interface, plus the search form, top left.

The search form has a label element which wraps the on-screen text “Search NYC.gov for”. That is perfect. None of the other 21 form controls on the other side of the page are correctly labeled. It really is kind of sad. In each of these 21 cases the code is almost correct. Each control has a label element around good on-screen text. But the for attribute never matches the id of the control. For example, for the “Street Name” entry field, the for attribute is for="stName" but the id is id="strName"! Close, but close isn’t good enough. It is like that for every one of the controls, not the same error – a simple and silly error.

Color Contrast

One of the accessibility requirements is that there be adequate contrast between foreground and background colors. We used to look a the page and guess whether or not the contrast was good enough. Now with the new W3C Web Content Accessibility Guidelines, we can actually measure that contrast and check if it meets the requirements. The Colour Contrast Analyser is available for download or can be opened from the Colour Menu of the Web Accessibility Toolbar.

The color contrast problem on the New York City site is just in one place on the page – actually on all pages – the main navigation links at the top of the page. The white on gray-blue links have a luminosity contrast ratio of 2.5:1. The requirement from the Web Content Accessibility Guidelines is a contrast ratio of 4.5:1. The background must be darkened. Here is an example, , that works both for the white link text and the black link text. They both give a contrast ratio of 4.6:1.

Search Results

I ften sample the Search results on a site I am reviewing for accessibility. I am impressed with the simplicity of the page of NYC.gov search results (screen shot below). But again there is absolutely no semantic markup and that is disappointing.

The obvious headings are not marked up as headings and the actual search results consist of a nested unordered list. If that list were marked up as a list, screen reader users could navigate the results much more efficiently. Similarly, if the individual titles in the search results list were marked up as headings, navigation would be a breeze.

Accessibility Scan of NYC.Gov

I used Worldspace from Deque to perform a depth 2 accessibility scan of http://NYC.gov consisting of the home page, NYC.gov pages linked from the home page and all pages linked from those. The scan found 52 unique pages with 736 accessibility errors or about 14 errors per page. That’s a lot!

When I use Worldspace for this task I tailor it to only look for errors that the testing software can be certain of. In other words I am not interested in dozens of pages of “potential violations.” There are around twelve such machine detectable errors. These include missing alt-text, empty alt-text on an image link, unlabeled form controls, no headings on the page, and no title attributes on frames.

Errors found in Depth 3 Scan of NYC.gov

For the Residents page Worldspace found four form errors (the form controls that are visible) and one error because there is no headings markup. Given how well the Residents page faired with alt-text, I was surprised to see 28 pages with 637 alt-text errors.

In his My e-Government Santa Wish #3: Benchmark Government Websites!, Michael includes Accessibility as one of four suggested components for benchmarking government sites, stating “Can be done largely automatic.” I balk at that because I know that automatic testing is so limited in what it can detect. However there is no doubt in my mind that the automatic testing results are symptomatic or representative. Lots of accessibility errors detected with human review – then there will also be lots of errors detected with automatic testing and vice versa. Illustrative of this is the fact that the NYC site had an average of 23 alt-text errors per page on which there were alt-text errors – for the DC site it is 21 per page.

Conclusion

So the idea here is to grade the NYC Residents page like I did the DC home page. Like DC, the New York City page gets an F for in-page navigation, lacking any headings markup.

Also very much like DC, for forms at least the developers knew something was supposed to be done and they just made mistakes. So as with the DC web site I am awarding a C for effort for forms.

Also for alt-text I grade A because all images do in fact have alt-text, though there are some errors in the quality of the alt-text down the center of the page.

Just like DC, the overall grade is C-.

As I said of DC.gov, this seems to be typical of government sites but I certainly did not expect to have an almost identical report for this site.

Next time, I will review the website of the City of Houston. They claim to be the most accessible city in the USA for people with disabilities. Let’s see if that also counts for their website.