Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional requirement - clarifying responsibilities #189

Open
alastc opened this issue Oct 2, 2020 · 4 comments
Open

Additional requirement - clarifying responsibilities #189

alastc opened this issue Oct 2, 2020 · 4 comments
Labels
migration: other Issues that do not fall into the other three categories

Comments

@alastc
Copy link
Contributor

alastc commented Oct 2, 2020

There is an implicit requirement that I think needs to be made more specific in Silver requirements:
The guidelines (in the sense of the whole spec / set of documents) need to make clear what the authors responsibility is.

It wasn't captured in the WCAG 2.0 requirements, but it is actually a topic that takes a lot of the discussion time and is one of the key rationales for various decisions. It will be more important to be explicit for WCAG 3 as it is not just for authors.

In a WCAG 3 context it could be generalized to being clear about author responsibility, AT responsibilities, tool responsibilities etc.

I don't have a strong opinion on where it is captured, perhaps as a Design Principle?
"Support various stakeholders in understanding what their responsibility is within the web technology ecosystem. For example, people writing web content can understand what their responsibilities are, and what aspects are the responsibility of the browser, assistive technology etc."

If it were captured as a requirement, it could be more of this form:
"Clarifying responsibilities
The supporting documentation makes it clear where responsibility lies for meeting each guideline. For example, whether it is something a designer or developer needs to do, or whether it can be met by relying on assistive technology, or a combination of both."

@alastc alastc added the section: Requirements Related to Silver Requirements document label Oct 2, 2020
@alastc alastc changed the title Additional requirement Additional requirement - clarifying responsibilities Oct 2, 2020
@jspellman
Copy link
Contributor

jspellman commented Dec 1, 2020

From the Silver meeting of 1 December 2020: RESOLUTION: We want to postpone addressing this issue until we have more concrete examples in our work. It has been the plan to address Accessibility Supported issue in a future version of the draft.

@jspellman jspellman added the status: revisit during future work Closed. This is not yet addressed but should be referred to when working on the topic in the future. label Dec 7, 2020
@alastc
Copy link
Contributor Author

alastc commented Jan 14, 2021

I think there are already concrete examples in the work, it is already being baked-in without being explicit.

For example, in alt text the outcome is:

"A text alternative for non-text content is available via user agents and assistive technologies, which allows users who are unable to perceive and / or understand the non-text content to determine its meaning."

It is (rightly) allowing for different methods, but there is no guidance as to who's responsibility applying the alt-text is. It could be the user-agent (via image recognition), it could be the author (planner/designer/developer), the CMS...

The how-to for captions includes (in a to-do note):

Explain the difference between what is done in the engine and what is done by the content developer.

There are sections in the how-to for plan/design/develop with comments like:

Ensure that the section headings are coded semantically — not just visually styled as headings, so that assistive technology can correctly interpret them.

The whole contrast guideline is based on it being an author responsibility, but we are going to hit issues where groups conflict (e.g. people with cognitive issues wanting less contrast or different colours), and personalisation is the best method for providing adaptation for everyone.

This isn't a FPWD issue, but it is something that should be accounted for in the requirements soon, and be part of the content stream of work.

If no decision or acknowledgement is made of this, I am concerned that the default will be like WCAG 2.0, where everything is the authors responsibility. If we are not conscious of the ecosystem as we write content, we will default to authors' responsibility because that is what we are used to (and that is where most of our guidance will be).

We are scoring on outcomes, but we need to establish how to include non-authoring scores pretty quickly.

I'm happy to join one of the silver calls if/when this comes up again, if someone can let me know in advance when it is on the agenda.

@Myndex
Copy link
Member

Myndex commented Jan 18, 2021

Hi Alastair @alastc Hi Jeanne @jspellman

Alastair said
> I think there are already concrete examples in the work, it is already being baked-in without being explicit.

Indeed, it is the basis of visual accessibility that I have been working on since 2019, though I have been much less public about that progress.

Jeanne said
> > Ensure that the section headings are coded semantically — not just visually styled as headings, so that assistive technology can correctly interpret them.

If there is one thing that needs to be a priority in terms of educating the public/designers, I think it is this. How many actually know this or follow it? It's an orphan, and not well disseminated. If ever there was a subject that needed a promotional campaign to raise awareness, I think this is it.

Tossing this out there: perhaps a useful Silver requirement would be a proactive approach in promoting the use of accessible guidelines.

Alastair said:

The whole contrast guideline is based on it being an author responsibility, but we are going to hit issues where groups conflict (e.g. people with cognitive issues wanting less contrast or different colours), and personalisation is the best method for providing adaptation for everyone.

The contrast guidelines I have been working on since 2019 definitely include personalization on the development plan. It is mainly in a rough white-paper stage at the moment, though some was in the draft I provided for FPWD at one point.

And one thing this last nearly two years of research has shown is that there is no "one size fits all" for accessibility. This is why the SAPC methodology and the APCA algorithm are based around a solid foundation of the science of human perception, from which best practices are derived for all impairments.

At the moment, there are specific technologies/APIs missing from CSS, missing from browsers, and missing from development environments. The "missing bits" are a blockade to the desired future of a "best for all" platform.

There's a proactive step in this I want to start, will discuss in email tomorrow.

A

@alastc
Copy link
Contributor Author

alastc commented Jan 18, 2021

Hi Andrew,

The purpose of this issue is to get something into the requirements, to say how different areas are included and contribute to conformance.

In the 'Scope' section there is this:

Support for the Technologies that Impact Accessibility: Advice for all levels of the accessibility technology stack who wish to support the WCAG 3.0 core Guidelines including:

With sub-bullets for content/tools/user-agents etc.

However, nowhere does it say that Silver will define who is responsible for what.

At the moment, there are specific technologies/APIs missing from CSS, missing from browsers, and missing from development environments.

Indeed, so in order to meet an outcome where there are things missing from the user-agents the responsibility may fall to the author. This needs to be an explicit process that guides how content is written and how outcomes are scored.

@rachaelbradley rachaelbradley removed section: Requirements Related to Silver Requirements document status: revisit during future work Closed. This is not yet addressed but should be referred to when working on the topic in the future. labels Jan 21, 2022
@rachaelbradley rachaelbradley added the migration: other Issues that do not fall into the other three categories label Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
migration: other Issues that do not fall into the other three categories
Projects
None yet
Development

No branches or pull requests

4 participants