Feedback on tagging in Silver IA prototype

To test the Silver IA prototype II did a quick walkthrough with various
tasks from the Silver job stories which highlighted some potential problems
with the way tagging is, and isn’t, used. For reference I have included the
selected job stories at the end of this email
Guidelines Specific guidelines

One group of common tasks involves people looking for specific guidelines,
eg colour, images and media, etc.

To successfully complete their tasks, the different users have to read
through a list of ALL the guidelines to find what they want. (With the new,
flat, 2-level approach this is a list of 78 guidelines.) This is because
there is no way of filtering or sorting the guidelines (only the methods).
Specific disabilities

Another common group of tasks involves people looking for guidelines
related to a specific disability. They have the same problem. There is no
way of finding this information without reading through all the guidelines.
The need to tag the guidelines

If the guidelines were tagged in different ways, the different users could
more easily find what they are looking for. In relation to the two problems
outlined above, two different sets of tags seem necessary.

One set of tags could organise the guidelines by aspects of the content
that are important for inclusive design, eg, Structure; Navigation;
Language; Colour and Contrast; Images and Icons; Video and Audio etc.

Quite how the tags are named and what they apply to is clearly up for
debate, but something along these lines would definitely help people
complete their tasks far more easily.

Another set of tags would be types of disability. Again, there would be a
need for a lot of discussion in exactly how this is done, but without any
kind of tagging in this way people, looking for information about a
specific disability can’t easily find it.
Accessibility specialists

Another common group of tasks were the users wanting to easily review all
the guidelines. They would simply be faced with a long list of 78
guidelines. This is one of the downsides of flat architecture.

For such users, some way of being able to structure the guidelines, so they
are more easily learnt, understood and remembered, would really help them
in their task. Tagging by content and disability (as suggested above) would
also help this type of task as well.
Tagging by principle

At the moment it is only possible to filter the methods in this way. If
such tags are going to be used, surely it should be possible to filter the
guidelines by principle as well.
Methods

To avoid any confusion, it is probably worth emphasising that in this
section I am referring to:

·       Methods in the way they are used in Silver to describe what are
currently referred to in WCAG as techniques.

·       I am also referring to the use of tags in the Methods section of
the IA prototype.
https://mikecrabb.github.io/silver_taggingSystemDemo/guidelines.html I am
NOT referring to the tabbed interface in the Plain Language prototype.
Methods in context

All the tagging in the Information Architecture prototype relates to
methods, and yet going through the job stories none of the tasks relate to
searching Methods in isolation.

The lack of job stories involving people searching for methods outside any
wider context is understandable. People are almost always interested in
methods in the context of particular guidelines and problems (not just
methods on their own).

That is another important reason why it is important to be able to tag the
guidelines. People are most likely to be looking at methods via the
guidelines, which is why they need to be able to easily find what they want
in the guidelines.
Tagging by “project stage”

It is unclear what it means to have methods tagged by “Project Stage”. How
would a “planning stage” method differ from a “design stage” method? If a
user ticked the “planning stage” tag for methods, what would this bring
up?

Tagging methods by “project stage” seems to be a category error: methods
can be differentiated by the device they apply to or the technology/coding
language they use, but not by project stage.
Long, undifferentiated lists

Even if we put these reservations about the current tagging aside, they
wouldn’t appear to work very well for users anyway.

Using the current tagging, if a developer did happen to be looking at the
methods section and ticked the tags for “mobile” and “development” they
would be confronted with a huge list of potentially hundreds of methods.
Quite how useful that would be I’m not sure.
Coding practice

Currently WCAG organises the techniques by HTML, CSS, Javascript etc and by
technologies (Silverlight, Flash etc). If you do happen to be looking
through the long list of techniques, they provide some structure and
coherence to the list.

Rather than having “Project Stage” as a category for tagging methods,
wouldn’t it be better to substitute a category to enable such ordering by
coding practice HTML, CSS, Javascript to continue? This could be extended
to included methods for frameworks and libraries, so for example, Angular
or React designer/developers could quickly find what they were looking for.

NB This would be in addition to the separate “Technology” tags, not a
replacement for them.

Tagging methods in this way, rather than by “planning/design/development”
has the added advantage that you don’t have to second guess how everyone
will subjectively understand and interpret what might be included in the
different stages of development.
Summary

·       The current system of tagging doesn’t enable many users to easily
accomplish their key tasks.

·       Being able to organise the guidelines by tags would enable these
tasks to be accomplished more easily.

·       One set of tags based around aspects of the content, and another
set of tags based around different disabilities would help a wide range of
users.

·       Tagging Methods by “stages of development” is a category error and
should be changed.

·       Methods should include a tagging category for coding practices.

·       All of these changes can be achieved within the current set-up
without any major alterations. It is essentially a matter of creating
different sets of tags, and applying them to different things.
Job stories reference

https://www.w3.org/WAI/GL/task-forces/silver/wiki/Job_Stories_for_Stakeholders
Job stories – Specific Guidelines

·       *Developer (novice):* When writing HTML, I want to browse the
{Silver} guidelines around semantics and document structure, so I can
improve the quality of my code.

·       *Accessibility designer* When selecting a color palette, I want to
confirm only applicable {Silver} criteria, so I can account for all
scenarios.

·       *Authoring tool developer* When writing output criteria for images
and media, I want to cite specific {Silver} success criteria, so I can
ensure that the CMS maps all required attributes, roles and values to each
asset.

·       *Influencer in disabilities* When advocating the use of audio
description, I want to quote relevant {Silver} guidelines, so I can build a
strong case for blind audience experience.
Job Stories – Specific disabilities

·       *Disability organization* When {Silver} is published, I want to
understand all guidelines that apply to the {particular disability} focus
of our organization, so I can address any gaps and advocate for greater
{particular disability} support.

·       *People with disabilities:* When I encounter a site that I cannot
navigate, I want to understand what {Silver} states about my explicit
problem, so I can cite the guideline when filing a complaint.

·       *Organizational policy* When prioritizing policy decision, I want
to fully understand the impact of {Silver} on unique audiences, so I can
consider the audience size and qualifiers of conformance.

·       *Influencer in disabilities* When speaking at an event, I want to
teach the audience about {Silver} guidelines, so I can reassure the
audience that cognitive and neurological impairments and concerns are well
documented and addressed
Job Stories – Accessibility specialists

·       *Accessibility specialist/helper/org* When {Silver} is published, I
want to study it in entirety, so I can renew certification.

·       *Accessibility consultant/advisor* When preparing to pitch a new
client, I want to refresh my working knowledge of {Silver}, so I can
dramatically increase the odds of being awarded the work

·       *Instructor/trainer* When considering renewing certification as a
credential, I want to review {Silver} guidelines, so I can determine the
degree of change and subsequent value of renewal.

 Mark Tanner