Structure is Guidance part II

One of the problems I see with the Electronic and Information Technology Accessibility Standards (Section 508) is how they are presented to the reader and the inherent priority presented the reader. Consider the current Access Board web page (http://www.access-board.gov/sec508/standards.htm) offers the following view:

Subpart A -- General
Subpart B -- Technical Standards
Subpart C -- Functional Performance Criteria
Subpart D -- Information, Documentation, and Support
Related Document: Preamble (published discussion of the standards).

The problem with this is that we start off talking about general exceptions, go into technical standards, eventually move into the purpose or functions the technical standards should perform, specify our administrative requirements for documentation, and then finally end with a discussion of the standards.
A new approach:

To help readers understand and hopefully make it easier to interpret and implement the accessibility standards, I suggest a change. Note that I've left the current subpart references (I didn't relabel them in order of A, B, C, D, as would be needed). I suggest the following order is more appropriate to interpreting the standards:

Subpart A – General
1194.1 Purpose.
1194.2 Application.
1194.4 Definitions.
1194.5 Equivalent facilitation.

Subpart C -- Functional Performance Criteria
1194.31 Functional performance criteria.

Subpart B -- Technical Standards
(the various technical standards here; note I also suggest changes to the organization of the technical standards so won't expound upon them here).

Subpart D -- Information, Documentation, and Support
Related Document: Preamble (published discussion of the standards).

Subpart E – General Requirements
1194.3 General exceptions.
119X.X Contract language.

Structure is Guidance

I'm convinced the structure of the Section 508 Technical Standards (http://www.access-board.gov/sec508/standards.htm) need to be changed during the refresh.

I can tell you that learning the standards and implementing them are two different things. What is important that in the process of implementing the standards one gets the experience necessary to understand what the technical standards mean and how the functional requirements map to the technical requirements. Also the relationship between the Subparts that don't necessary follow (or at least are not clear) the alphabetical hierarchy (A, B, C, or D.)

So now I suppose the burden is upon me to outline my suggested approach so everyone can debate the approach.

Please provide feedback on accessibility topics

If you are interested in getting people involved in the refresh to the Section 508 Accessibility Standards, please consider posting the following message to your lists:

Have an opinion on how legal issues and technical standards impact your work? Does accessibility impact your development? Does it affect your customers? Does it affect you? You might be interested in providing recommendations for updates or feedback to to the refresh of the U. S. Section 508 (http://en.wikipedia.org/wiki/Section_508) Accessibility Standards.

This effort is being coordinated on an international scale. This is an open process, please consider participating! More information is available via http://teitac.org along with the notice via http://www.access-board.gov/sec508/update-index.htm.

Please share this message as appropriate. We think this message is appropriate given this forum, please excuse us for this one-time posting if unwelcome.

This is important because many people are working in topics related to accessibility that contribute to the Section 508 refresh but are unaware of this public activity.

Welcome!

Well, I'm opening up shop here to record some of my accessibility ideas and share them with others who are interested.

Most of this content should be related to Section 508, specifically the Section 508 refresh that is currently underway. I might post arguments and topics and provide references to other locations where I think the ideas are of interest.

Please do provide feedback. Meaningful feedback is welcome as is any corrections or additional information related to the topic at hand.