RE: Front-matter

Alastair,
While I am unsure of the answer of how best to adapt these technical reports, I am always of the mind that they can improve. You say “once you are trained to read it, sheet music is ‘easy’ to read.” In my experiences working with trained musicians with cognitive disabilities, and working with those trained to write or use specs (who have cognitive disabilities), the issue can be the extra amount of time those individuals may need to complete the task because of the presentation of the information. The training teaches a person the structure, meaning, and the ability to decode the information. This does not mean that because of the training, their disability no longer impacts their ability to perform the task. Just because a person is trained to read music or technical documents doesn’t mean they can read it with the speed or ease of others that are similarly trained.
If we discuss what one vendor is terming “learning tools” that enable a person to adjust the font spacing, font, add symbols, and the ability to use text to speech tools within documents, imagine a time where a technical document could have the same type of features. If a person was able to customize them to meet their individual needs without impacting the original document, then everyone that wanted access could have it.
In the meantime, I believe it is the job of advocates to keep asking “does this have to be written like this” and “is there a better way given the tools and structure currently in place?”
I too believe that we should start with “how do we cause the most impact, make the biggest change overall” but do this while keeping track of the current barriers and find ways to reduce them.
Respectfully,
Jennie

Jennie Delisi, MA, CPWA
Accessibility Analyst | Office of Accessibility
Minnesota IT Services | Partners in Performance
658 Cedar Street
St. Paul, MN 55155
O: 651-201-1135
Information Technology for Minnesota Government | mn.gov/mnit<http://mn.gov/mnit>
[Minnesota IT Services Logo]
[Facebook logo]<https://www.facebook.com/MN.ITServices>[LinkedIn logo]<https://www.linkedin.com/company/mn-it-services>[Twitter logo]<https://twitter.com/mnit_services>




From: Alastair Campbell <acampbell@nomensa.com>
Sent: Sunday, September 9, 2018 12:04 PM
To: Rochford, John <john.rochford@umassmed.edu>
Cc: 'COGA TF' <public-cognitive-a11y-tf@w3.org>
Subject: 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