W3C home > Mailing lists > Public > public-cognitive-a11y-tf@w3.org > September 2018

Re: Front-matter

From: Steve Lee <steve@opendirective.com>
Date: Thu, 13 Sep 2018 10:28:18 +0100
Message-ID: <CAEsWMvQwi6FKkk1WxeL=jignU2uFG8DO39d6eWPdRgMYpa+Maw@mail.gmail.com>
To: Alastair Campbell <acampbell@nomensa.com>
Cc: COGA TF <public-cognitive-a11y-tf@w3.org>
Thanks for looking into this Alastair. However, no, I don't think it
does completely make sense as you ask at the end

> The intended audience for this document is people who write documents with this kind of front-matter & format.

That struck me as being in danger of the tail wagging the dog or even
"it's always been that way"  :).

I agree a standard format is important - but not if it obscures the
main content.  I for one get really frustrated reading all the front
verbage of the W3C specs i want to understand. Especially as the
signal to noise ratio is usually very low given it's more about the
W3C process not the specs content. But then you probably hint at one
reason W3C specs are like this :

> The gap-analysis (as chartered) is aimed at spec-writers

Surely the audience for this and any W3C doc is anyone who wants to
help shape the specs or use them to improve what spec-readers create?
Not just spec writers producing more of the same? My understanding is
the W3C desire more people to be engaged and WAI specs should clearly
represent the preferences of the people they ultimately address. Let
alone the need for us to be fully inclusive in our activities?

So the tension I see here is between wanting to make the documents
easily accessible to everyone who might want to contribute to the spec
formation and keeping a consistent structure. My sense as a keen spec
user is that balance is not quite right. I know there are other docs
that are designed to help understand spec and apply them. but they are
1 step removed from the 'master' and may be out of date. I've no doubt
this topic has been thrashed out in lots of long threads but I do
think coga is moving the goal posts to some extent and may need a
modified approach to some extent. That could be as simply as a little
restructuring of the necessary boiler plate material and providing
less "academically rigorous" introduction for an audience that is no
"spec-writers".

I don't have a solution but it would be good to explore it more. I
realise that pushing too hard would open a great big can of worms and
could easily sidetrack the very limited effort we have available. So
we'd need to find a way of making the specs more accessible that is
readily acceptable by those who are content with the status-quo given
requirements prior to coga getting more mind share,

At least for now :)

Steve Lee
OpenDirective http://opendirective.com


On 6 September 2018 at 22:54, Alastair Campbell <acampbell@nomensa.com> wrote:
> Hi Everyone,
>
> I was going to investigate the 'front-matter', regarding the easy-read overview being worked on and what flexibility there is.
>
> Looking into it [1], the "status" section is very formulaic, practically hard-coded.
>
> There are less rules for the "Abstract", except that there has to be one (called Abstract). There are some very strong conventions around what it says (see any of the "Technical Report" docs [2], the clue is in the name).
>
> What I spectacularly failed to say on the call was:
> The intended audience for this document is people who write documents with this kind of front-matter & format.
>
> The gap-analysis (as chartered) is aimed at spec-writers and, regardless of ability/disability, reading & writing specs is something they are used to. Not following the format would make it less usable for that purpose/role/audience. For example, "examples of people and their Web problems" is not accurate enough for this purpose & audience.
>
> That does not apply to the coga-usable doc, for which there is a good argument to make it super-clear, and perhaps avoid the 'stuff' that has to be added to a TR doc. That could be done by publishing it in the WAI area like the techniques & understanding docs for WCAG.
>
> Having said that, there are certainly improvements to make in the gap-analysis abstract, and there is no objection to an easy-read overview in the introduction.
>
> For example, with the coga-usable document separated, it should be tweaked to reflect that. Combing the current and easy-read version, I would suggest something like:
> -------------------
> This document focuses on the state of accessibility for people with learning and cognitive disabilities when using the Web. It builds on the Cognitive Accessibility User Research [coga-user-research] and Cognitive Accessibility Issue Papers [coga-issue-papers].
>
> This document provides:
> *        a summary of issues and techniques,
> *        unmet user needs,
> *        suggested ways technologies may meet these needs in the future.
>
> This document is produced by the Cognitive and Learning Disabilities Accessibility Task Force (COGA TF), a joint task force of the Accessible Platform Architectures Working Group (APA WG) and the Accessibility Guidelines Working Group (AG WG) of the Web Accessibility Initiative.
>
> For more general advice on supporting people with learning and cognitive disabilities see "Making content usable for people with cognitive and learning disabilities" [coga-usable].
> -------------------
>
> Does that make sense?
>
> -Alastair
>
> 1] https://www.w3.org/pubrules/doc/rules/?profile=WD
>
> 2] https://www.w3.org/TR/2018/CR-css-cascade-3-20180828/
>
> 3] https://rawgit.com/w3c/coga/master/gap-analysis/index.html#abstract
Received on Thursday, 13 September 2018 09:28:43 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 September 2018 09:28:43 UTC