Questions from SUNY TC Webinar entitled
NYS OFT ACCESSIBILITY POLICY - An Explanation and Discussion
October 5, 2004

Presenters: Patrick DeCastro & Debi Orton, NYS Office for Technology

1A) If there is a link to download Adobe reader on the page, would posting a PDF be acceptable? It is my understanding that PDFs are accessible documents - especially since the newer versions have a built-in screen reader.

1B) To be clear, are you saying that if we provide a link to the PDF reader, that will suffice to allow PDF files on the Internet? (same/similar question from two participants)

We'll answer both of these questions together, since they're so similar. First, we'll dispel some misinformation. The latest version of the Adobe reader does not include "a built-in screen reader." Nor are PDFs what can be classified as an accessible document. A truly accessible document is one that the site visitor needs no more than a browser to access. What is different about this version of Adobe PDF files is that they can be used with screen reading software, provided:

  1. The PDF document is correctly prepared (structured and "tagged")
  2. The PDF document has been generated from text and is not a scanned image
  3. The visitor has the latest version of Jaws
  4. The visitor has purchased a full copy of Adobe Acrobat (not just the reader)

This excludes the 45% or so of people with visual impairments who use alternative screen reading software (i.e., not Jaws), excludes anyone using an older, less powerful computer incapable of running the latest versions of Jaws and Acrobat, can potentially exclude people using dial-up Internet connections, and will exclude anyone using a web-enabled cell phone, a PDA or Web TV.

Unless there is a legal reason to post a document in PDF - for example, forms in PDF format for site visitors to print out and complete (and adequate provisions are made for people with visual and/or motor impairments to receive assistance with completing/submitting the forms), we advise that web developers post documents in an accessible format (e.g., HTML, XHTML, or plain text) or post an equivalent document in an accessible format IN ADDITION TO the PDF document.

For more on the treatment of PDF and other proprietary formats, please refer to the FAQ document on the NYS Forum's IT Accessibility Committee's web site, in the NYS Policy and Standards section, and in the Validation and Testing section, in the GTC Presentation files:

2) Patrick indicated in one of his first slides a specific section of the law listing the state agencies that MUST be in compliance with the new accessibility policy. Where can I read the full text of that section so I can determine for certain whether my department must be in compliance?

Here's the citation you're referring to:

State Agencies as defined in Executive Law §205(4). . . any department, board, bureau, commission, division, office, council, committee, or officer of the State. . . does not include the legislature or the judiciary.

This refers to Executive Law Article 10-A:

Section 205. Definitions.
206. Office for technology; director, organization and employees.
206-a. Functions, powers and duties of the office.
207. Advisory council for technology.
207-a. Functions, powers and duties of the council.
208. Responsibility to respond to the freedom of information law for certain data.
208-a. Severability.

S 205. Definitions. As used in this article the following terms shall mean:

3) I'm unclear about how to make forms accessible. You mentioned something about implicit?

The reference to "implicit" was made in regard to labels for form controls. Simply stated, you are required to provide a descriptive label element, connected to the form control by the use of the ID attribute of the form control. This is an explicit label. The exception to this would be for form controls which have an implicit label, such as a radio group or a button.

The specific requirements of the policy, including code samples, can be found on the NYS Forum's IT Accessibility Committee's web site: in the section on NYS Policy and Standards, and in the Forms section.

4) Are course pages and electronic reserves (?) considered "intranet" since they are passworded and have a specific audience?

We are not sure what an "electronic reserve" is, but if a site's access is restricted and the audience is known, it would be considered an intranet. The policy and standards also pertain to intranets, but there is a provision that allows for the use of documents (e.g., posting MS Word documents) that would not be considered accessible on a public Internet site, so long as the hardware/software used is controlled by the agency. However, if there is an individual with a disability in that limited audience, accommodations must be made to ensure that the disabled individual has equivalent access to information and services.

There is a potential problem here, however, because any one of us can become temporarily - or permanently - disabled at any time. Unless there is a compelling reason to do so, it doesn't make sense to create a site with barriers.

5) Are there any tools available to determine compliance with this policy for individual pages or the site as a whole?

Yes, there are several, and most of the free ones test a page at a time. You can find for-fee packages and services that will deliver reports on your site as a whole (the downloadable version of Bobby is one). We prepared and delivered a program at the GTC conference in Albany that discussed web site testing and focused on free tools available to test your site.

You can find both the materials from the GTC session and other tools and resources on the NYS Forum IT Accessibility Committee web site, at the URL provided above. You can find these resources in the Validation and Testing section of the site.

6) Patrick referred to a source for best practices as determined by a group of experts. How can we join this group to help assist in the formation of these policies prior to their activation?

When the initial policy (Technology Policy 99-3) was developed by the Office for Technology (OFT) in 1999, a working group of web developers, policy analysts, and advocates for the disabled worked together to evaluate and recommend the various standards for accessible web development.

At that time, we felt that the World Wide Web Consortium's Web Content Accessibility Guidelines (WCAG) version 1.0 offered the most comprehensive support and resources for implementation, and elected to adopt those as our standards. Because we wanted to ensure that we would always be working with the latest edition of the WCAG, we embedded language in the policy that specified the "current version" of the guidelines.

Subsequent to Technology Policy 99-3, two things happened. The Federal government adopted Section 508, part of a larger set of accessibility regulations, and the Web Accessibility Initiative (the workgroup responsible for the WCAG) began the process of replacing WCAG 1.0 with WCAG 2.0. The framework for 2.0 was completely different than the framework we had adopted with WCAG 1.0, and we felt it would be more difficult to work with.

With 99-3, a formal IT Accessibility Steering Committee (ITASC) was formed to monitor developments in accessible web design and make the appropriate recommendations to the Office for Technology. When it appeared evident that WCAG 2.0 was close to adoption, the Committee performed a detailed analysis and comparison of Section 508 with WCAG 2.0. We found a lot of similarities, but some differences, and after long discussions, elected to propose a hybrid policy that combined elements of both standards, along with several "best practices."

As OFT's policy development process was restructured, the agency looked to the people who had helped develop the original policy and related training and initiatives. Many of these people were now participants of the NYS Forum's IT Accessibility Committee, and the Forum brokered a relationship between OFT and that Committee, which now serves OFT in an advisory and support capacity.

If you would like to participate in our current implementation efforts, and the future evolution of the policy and standards, I encourage you to join the IT Accessibility Committee and become involved in the initiative. You can find information on the committee on the NYS Forum web site at

7) .htaccess is server-side and should be ok. . .client-side (javascript or page headers) causes problems with this policy.

This answer may not be precisely on point, as we're not clear what this comment/question was in reference to. As we understand it, .htaccess is a means of restricting access to a directory. While JavaScript can be used to restrict access, it has wider use in the manipulation of information on the web page. The problem with client-side scripting is not necessarily for authentication, but the fact that there are potential site visitors out there that can't or won't enable JavaScript in their browser. Consider the users with no native processing capability, such as PDAs, web-enabled cell phones and WebTV, as well as a new class of "malware-phobes."

If you use server-side scripting instead, whatever manipulation needs to transpire can be done on the server side and rendered in compliant HTML or XHTML.

8) Is the HorizonWimba Webinar Interface Accessible?

Yes, for more information on the accessibility of Horizon Wimba and how the system manages screen readers, please go to