RE: Front-matter

Hi John,

Thank you for that, it's an important discussion that I'd like to continue in that manner.

I think there are two principles/concepts that will help explain my perspective:


  1.  Ability/disability and level of experience (with a particular domain) are different continuums. I would be very surprised if there were not people with cognitive disabilities writing specs. I don't know either way, I'm not in a position know, but my assumption is that there are.

  2.  I think we'll achieve more by writing particular documents for particular audiences.

So I completely agree with your second point that people with cognitive disabilities write specs, I assume that is the case.

Regarding "which specs don't need to be super-clear", I'd say none, but clarity is subjective and the important continuum for this is experience & purpose. (I'm going to borrow heavily from something JohnF wrote recently, as he said it very well.)

The technical report documents are primarily engineering documents, not written for general consumption and they are clear to the intended audience, including people with cognitive disabilities. Not everyone, certainly. I was reading a colour-space doc recently and couldn't understand very much of it, but I'm not an engineer in charge of rendering colours. I could understand it's purpose and status though, as it matched the format I'm familiar with.

To take an example from another domain, it's like reading sheet music: once you are trained to read it, sheet music is "easy" to read, but if you don't know how to read sheet music then you can't make it easier for its intended purpose.


> this too appears to imply that reading & writing specs is something people with cognitive disabilities aren't capable of, so aren't used to.

Reading & writing W3C specs is complicated for any reader unaccustomed to them, in the same way that sheet music is something that anyone without musical training and practice would not be able to read. Most people without cognitive disabilities struggle to understand W3C technical report as they lack the training/experience to do so.

My main point is that we should write for the audience, which *in this case* have a familiarity and expectations about how technical reports are written. That is the only assumption I'm making.


> led me to believe that, once again, the COGA Task Force would not make any progress helping the W3C be inclusive.

To me this is a different question. We (me, chairs, W3C team and every member & invited expert) should aim to make the W3C an inclusive place to contribute, communicate and learn.

An aside: I'm reviewing the process feedback at the moment, and trying to work out how to: produce HTML output documents; have multiple methods of collaboration and contribution; AND not have multiple places for things so everyone loses track. It is a difficult thing to do, but we will do our best.

The bigger question is: how do we cause the most impact, make the biggest change overall?

I firmly believe that the communicator has to bridge gaps in understanding. I.e. you write for the intended audience.

There are several audiences with different expectations and needs (none of which are related to whether someone has a disability):

  *   Standards writers / readers;
  *   Policy makers (not technical/engineering)
  *   Browser implementors, tool creators, etc.
  *   Website / application designers/developers/content writers etc.
  *   End-users of the websites/apps.

What are the most successful types of writing for each audience? W3C, WHATwg, ISO, all have standard ways of doing things for engineers that they have optimised over time. BUT, they are not successful for general website authors or end users.

Places like MDN and stackoverflow are much more useful/efficient from a developers point of view. But note that the articles & answers will reference the standards frequently. We should make efficient use of time by producing a suitable document for the audience, which then has a wider impact.

After the call I looked at the content of the abstract, I looked at the easy-read draft, and I don't think replacing the abstract with it will help.

For example, these sentences do not have the same meaning:
1a) focuses on people with cognitive disabilities.
1b) focuses on the state of accessibility for people with learning and cognitive disabilities.

2a) explains problems people often have with the Web.
2b) a summary of issues and techniques.

I think the easy-read version would be perceived as misleading and put off the very audience we want to use the document.

That applies to this very particular type of document, we should be spending the time and effort where it will have the most positive impact.

My suggestions would be to:

  *   Focus on the coga-usable document, it doesn't have an easy read intro yet.
  *   Discuss with the EO group publishing it under the WAI area so it isn't required to have the same front matter. As an added bonus, the styling is nicer.
  *   Make sure it gets linked to from the 'supplemental guidance' area created for 2.1.
  *   Look at the typical route<https://www.google.com/search?q=web+accessibility&ie=utf-8&oe=utf-8&client=firefox-b-ab> into web accessibility, the WAI intro. How could that be improved?
  *   Keep an eye on the silver discussions, so that easy-read is part of the next version.

Sorry for the long email, from a simple question there was a lot to unpack.

All the best,

-Alastair