Re: Front-matter

I've got a little out of step with this [excellent] discussion

Jennie wrote:
> 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.

That's a VERY healthy mindset right there!
We are highlighting the need for some improvement. As Jan says

> This is where I think the problem ultimately lies with respect to
including people with disabilities.  We are expecting them to adapt to the
existing model and we don't have any real expectation that the model will
adapt to them.  That should not be how the Web Accessibility Initiative
operates. "

Alastair wrote:
>

Is there is another way of making it easier, whilst covering the same
information and keeping it consistent with other specs? (Needed for
everyone, including people with cognitive disabilities.)

I’d love to understand how to do that.

I think that's our task in a nutshell!
Making the specs more accessible but also meeting the existing existing
quality features (unless they get redefined as a result course)

> 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.

Given your experience and what we've been saying, I'm sure it's a good plan
to fit it with existing process while highlighting the new requirements we
are identifying.

So it seems we are settling on a 2 pronged approach

1) Make the absolutely best resources we can for supporting people with
cognitive preferences and also strongly encouraging them to engage
2) Work on the bigger picture of how the wider W3C WAI process and specs
might be enhanced to be more accessible to our 'audience'

Let's separate them out rather than mixing them up as we seem to have so
far.

Speak soon


Steve Lee
OpenDirective http://opendirective.com

On 10 September 2018 at 14:17, Delisi, Jennie (MNIT) <
jennie.delisi@state.mn.us> wrote:

> 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
> <https://maps.google.com/?q=658+Cedar+Street+%0D%0A+St.+Paul,+MN+55155&entry=gmail&source=g>
>
> St. Paul, MN 55155
> <https://maps.google.com/?q=658+Cedar+Street+%0D%0A+St.+Paul,+MN+55155&entry=gmail&source=g>
>
> O: 651-201-1135
>
> *Information Technology for Minnesota Government* | mn.gov/mnit
>
> [image: Minnesota IT Services Logo]
>
> [image: Facebook logo] <https://www.facebook.com/MN.ITServices>[image:
> LinkedIn logo] <https://www.linkedin.com/company/mn-it-services>[image:
> 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
>