Re: Front-matter

Hi Everyone,

I am sorry that I am late to the party with my comments on this thread, but
here goes....

Alastair, thank you for your thorough review of what has been done
historically in the W3C and for your thoughts on the easy reading summary
vs. the current abstract.  I believe you are genuinely working on a way
forward, and I appreciate that.

I want to point out an observation that I believe is relevant to the
discussion.  We all know that there are people with cognitive disabilities
who are involved in standards work.  I do not believe that is what we are
contesting.  I believe that the problem we are trying to bring to light is
that the effectiveness of people with cognitive disabilities in standards
work is compromised by the processes currently in place.  We have ample
evidence of the fact that very little forward progress has been made in
this space for well over a decade.  This is the problem we have to fix.

The process of standards work itself has to become more inclusive of people
with disabilities and that starts with all of us being more sensitive to
the assumptions we make about what is and is not important for people with
disabilities.  Many of the people on the COGA task force have cognitive
impairments of various sorts. The message they have been trying to convey
to the broader working groups is that their voices are being stunted by
processes that are not accessible to them or inclusive of their needs.  If
the brilliant, technical people on the COGA task force are saying this,
then we need to be honest with ourselves that the entry ramp for other
people with cognitive disabilities to be involved in standards work is
filled with obstacles that will likely keep them from being involved.
Whether those obstacles are placed there intentionally, or by accident, the
result is the same:  people with disabilities are being excluded.

I know that this is not something that any of us want and I also realize
that this is not going to be a simple problem to solve. With that said, we
will never solve this problem if we compromise on the basic principle that
people with disabilities should be an integral part of developing the web
standards that will define their access to information technologies.  In
order for them to be a part of the process, the process has to be
accessible to them.

I don't think that we are moving forward on our discussion by debating
whether to have an easy reading summary OR an abstract.  Ideally, we would
have both and even more ideally, the abstract would not be difficult to
understand.  I agree with Alastair that there is going to need to be a
certain level of technical understanding and experience for standards work,
but I also believe that it's not a one-way street.  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.

So, while I agree that we should focus on COGA documents and making them
easy to consume, I think we also need to maintain our focus on how to
improve the overall standards process so that it is more inclusive and
easier for people with disabilities to have an effective voice.


Jan McSorley
VP, Accessibility
Psychometrics and Testing Services

400 Center Ridge Drive, Suite E
Austin, TX  78753
M - (512) 673-9569
Twitter: @Jan_McSorley
Skype:  jan.mcsorley
www.linkedin.com/in/janmcsorley

Learn more at pearson.com

[image: Pearson]

*We put a man on the moon in the 1960's ... surely we can make information
technology fully accessible to people with disabilities.  It can be done
... it must be done ... it will be done!*

On Mon, Sep 10, 2018 at 9:18 AM, Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi Jennie,
>
>
>
> Welcome by the way!
>
>
>
> I agree with pretty much everything you said. I’d also note there’s a wide
> variety of cognitive disabilities, I’ve met some people who are far more
> efficient at reading specs than I am!
>
>
>
> I’m not sure whether you saw what we’re comparing? It is the current
> abstract for the gap-analysis:
>
> https://www.w3.org/TR/coga-gap-analysis/#abstract
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_coga-2Dgap-2Danalysis_-23abstract&d=DwMGaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=ksuXVmJb3l3QDSARdyyNqYB9mIN46ysrp3N8eQ8CENY&m=K1mFOX0crp8oW443nkcXPjDF_7yfIA7_Kz0bQtw_jLY&s=FdUFV1mWam_V-OtCy0pj2wvm6zqki5KhPrEzuF4ZqXM&e=>
>
>
>
> With an easy-read version:
>
> https://lists.w3.org/Archives/Public/public-cognitive-a11y-
> tf/2018Aug/0013.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.w3.org_Archives_Public_public-2Dcognitive-2Da11y-2Dtf_2018Aug_0013.html&d=DwMGaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=ksuXVmJb3l3QDSARdyyNqYB9mIN46ysrp3N8eQ8CENY&m=K1mFOX0crp8oW443nkcXPjDF_7yfIA7_Kz0bQtw_jLY&s=jG5teIrT2EZdiOZlAEPsR87Nj_WD2GmJgXzBtWOwqn0&e=>
>
>
>
> I tried to do exactly what you said:
>
> > “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?”
>
>
>
> And posted an intermediate version that tried not to lose the meaning
> needed for the abstract:
>
> https://lists.w3.org/Archives/Public/public-cognitive-a11y-
> tf/2018Sep/0008.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.w3.org_Archives_Public_public-2Dcognitive-2Da11y-2Dtf_2018Sep_0008.html&d=DwMGaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=ksuXVmJb3l3QDSARdyyNqYB9mIN46ysrp3N8eQ8CENY&m=K1mFOX0crp8oW443nkcXPjDF_7yfIA7_Kz0bQtw_jLY&s=R-Ho_A7J_NhdyH236NzJwD9JIZz41dSfGh1n26kRXmc&e=>
>
>
>
> I’m not saying that is perfect by any means, but it includes:
>
>    - the context, i.e. previous docs it is building on;
>    - the groups responsible, and
>    - terms that more accurately describe the content (which is much more
>    subjective on my part).
>
>
>
> Also, since John wrote the easy-read version we’ve decided to separate
> part of it off, so I didn’t include some items as they will be removed. It
> was also written without anyone specifying where it would go, the thought
> to replace the abstract came later so it is not surprising it doesn’t
> contain quite the same information.
>
>
>
> 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.
>
>
>
> All the best,
>
>
>
> -Alastair
>
>
>
>
>
> *From: *"Delisi, Jennie (MNIT)"
>
>
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mn.gov_mnit&d=DwMGaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=ksuXVmJb3l3QDSARdyyNqYB9mIN46ysrp3N8eQ8CENY&m=K1mFOX0crp8oW443nkcXPjDF_7yfIA7_Kz0bQtw_jLY&s=JKne5uez33fDmhaDGqCI7ZLru4yegSEY9rrWt93XOWU&e=>
>
> [image: Minnesota IT Services Logo]
>
> [image: Facebook logo]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_MN.ITServices&d=DwMGaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=ksuXVmJb3l3QDSARdyyNqYB9mIN46ysrp3N8eQ8CENY&m=K1mFOX0crp8oW443nkcXPjDF_7yfIA7_Kz0bQtw_jLY&s=e0TQS1k9yIn5bAWM9WbpP-UT88zLO8hZhI7rb0wDhis&e=>[image:
> LinkedIn logo]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_mn-2Dit-2Dservices&d=DwMGaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=ksuXVmJb3l3QDSARdyyNqYB9mIN46ysrp3N8eQ8CENY&m=K1mFOX0crp8oW443nkcXPjDF_7yfIA7_Kz0bQtw_jLY&s=FlLS3eXIwpU--iRJPOyY4slrFw66FjSJMApCS3nrHgI&e=>[image:
> Twitter logo]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_mnit-5Fservices&d=DwMGaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=ksuXVmJb3l3QDSARdyyNqYB9mIN46ysrp3N8eQ8CENY&m=K1mFOX0crp8oW443nkcXPjDF_7yfIA7_Kz0bQtw_jLY&s=L_DarBzKn093GVKqEl5wGSZla_7Q3sgEdFL6G_f2KsQ&e=>
>
>
>
>
>
>
>
>
>
> *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
>