WCAG/ATAG compliance, or at least better accessibility than today.

[AndreasJacobsen]

Documentation Issue

WCAG stands for "Web Content Accessibility Guidelines", ATAG stands for "Authoring Tool Accessibility Guidelines". These guidelines make ICT-solutions more accessible.

In my company we have a blind employee, he is very good as his job and is as excited as me to find a new CMS-system. But upon a quick inspection of we found several issues that make PayloadCMS very hard for him to use.

Some parts of WCAG are difficult to understand and require allot of work to get right, others are easy to fix. The first WCAG breach we found was 4.1.2 Name, Role Value.
The buttons in the rich text field editor lacks alternative text, all the buttons are simply announced as "button"

The fix for this is relatively simple, assign an accessible label for each button using aria-label and allow users to assign aria-label attributed on custom buttons.

Additional Details

We are in the early phases of choosing a new CMS, PayloadCMS ticks allot of the boxes but falls short when it comes to accessibility.
As this is an open source project we could probably fix allot of the issues ourselves and use them in our solution, but this won't help other Payload users. We could create PRs to fix things, but we are accessibility experts; not developers. We do not feel the quality of our code meets the quality found elsewhere in PayloadCMS.

Why should we care about WCAG?

WCAG compliance makes for better solutions for everyone, not just those with a disability. Things like proper focus highlight with sufficient contrast is necessary for keyboard users, but nice for everyone else too.

How can the freeloading author of this issue help?

I am an accessibility auditor, I can help audit PayloadCMS using screen readers and auditing tools. But before I spend god knows how many hours on that I need to know that accessibility is something you care about and want to maintain.

Will this make PayloadCMS money?

Part of my job as an accessibility consultant is to evaluate external ICT solutions. See if the work for employees (current or future) with disabilities. In my country (Norway) all public facing ICT-solutions are required by law to be WCAG compliant, in the EU this only applies for the public sector. If I did this for PayloadCMS the answer would simply be "you cannot use this, it is not accessible enough". Which is sad - the front end code quality is better than allot of others things I've tried.

How can we tell if we follow WCAG?

Automated tools such as Axe Devtools can find around 30-50% of the WCAG-issues. The rest requires manual testing. Writing WCAG compliant code is really just writing "good" proper HTML. In my experience work towards WCAG compliance usually leads to higher quality and more robust HTML/JS code in projects.

[TomDo1234]

This seems like a really important thing that the Payload developers can add!

I am in the middle of doing another Pull Request and adding my own contributions to the project.

After my pull request gets reviewed and merged this will be my next task as a volunteer. Will you be willing to help out and guide me to make things more accessible for everyone? @AndreasJacobsen

[jmikrut]

Hey @AndreasJacobsen thanks for bringing this up. The Payload team agrees that this is high priority for us to tackle. We're going to sink some time into bringing the admin UI up to a better spot re: accessibility immediately, and make it a goal of ours to ensure all future development is done so with a mind toward ensuring a high degree of accessibility moving forward.

As this is a moving target, and will need to be addressed on an ongoing basis, I am going to convert this to a discussion. But the team and I will report back on the discussion once we have made progress, and we would welcome progress from the community here as well! @TomDo1234 it would be absolutely amazing if you could contribute here as well. We would GREATLY appreciate it!

[AndreasJacobsen]

Turns out that we cannot use PayloadCMS because it does not support our workflow and structure. So we have stopped the trial project for using Payload.
That said I can still help with some accessibility testing, especially low hanging fruits. Next low hanging fruit - landmarks!
Landmarks are programmatic ways to describe sections of a page you can see, see an example of landmarks in use at https://www.w3.org/WAI/ARIA/apg/example-index/landmarks/index.html.

Headings (and heading levels) is one of the most common ways to navigate webpages for blind users. But for web applications (instead of websites) that users use allot landmarks are often used extensively. They let you very quickly jump between distinct sections of a page.
Whenever a landmark is used more than once it must have an unique accessible name assigned via aria-label or aria-labelledby. Can you tell where the landmarks in the screenshot bellow go? And where is the main content of the page (<main>)?

For the navbar I see three

-landmarks that each could be easily labelled by their "list heading"

<!-- Aria-expanded indicates that a button expands something, and expaded state -->
<button aria-expanded={true} id="collections">Collections
    <!-- SVG is announced by screen readers, but without a name they are announced without meaning
    We communicate expanded state using aria-expanded, so the expanded icon should be hidden using aria-hidden -->
    <svg ... aria-hidden="true"> </svg>
</button>

<!-- <nav> creates a navigation landmarks. Announced when you  enter/leave the landmark and available through landmark navigaion -->
<!-- By using aria-labelledby instead of aria-label we guarantee that the visual text is the same as the text announced by screen readers -->
<nav aria-labelledby="collections">
    <uL>
        <li><a href="/forms">Forms</a></li>
        <li><a href="/formsSubmit">Form submissions</a></li>
    </uL>
</nav>

[jmikrut]

Hey @AndreasJacobsen —thank you for the follow-up!

because it does not support our workflow and structure.

Can I ask what is preventing you from using Payload? Would love to know.

Thanks again!

[AndreasJacobsen]

Hello @jmikrut! Our workflow is "special", and we like to think of ourselves as special people. As such supporting our usecase is probably not useful for everyone else; but might be!

What do we need from our CMS?

We use our CMS to do accessibility audits, we also host our website on our cms but this is a very small part of the CMS. Today we use Sanity for this, but our structure is too complex for Sanity to handle and we are reaching some of Sanity's hard limits (attribute limit).

How does an accessibility audit look?

Our audit are structured sort of like WCAG. Structure is ish as follows

• Audit summary
• WCAG principles (4 of these), each principle contains many guidelines (example guideline 1.1 Text Alternatives)
• WCAG guidelines, each guideline containes many success criterion (example 1.1.1 Non-text content)
• WCAG sufficient, advisory and failure tecniques, these are concrete ways WCAG success criterions can fail or succeed. For example "Using aria-label to provide labels for objects"

Each audit currently contains 186 unique "tests" and results in 100+ page reports, the number of testpoints is planned to increase by at least 50 test cases this year.

How do we do this in Sanity (our current CMS)?

Arrays, so many arrays.
Principles are an array of guidelines, guidelines are an array of success criterion.
success criterion are an array of failure criterions.
Every audit is on "one page" in the CMS.
This allows us to open up just the success/failure criterion we need to work with and let's the audit page not be as long as it could have been.

Why can't we do this in PayloadCMS?

Multiple people work on one audit at the same time, this a must have for us. It seems like PayloadCMS does not support multiple people at once.
That is not really a deal breaker, but rather a nice to have. What is a deal breaker is that (from our testing) an entire audit needs to be in one collection. You cannot open sections from other collections and work on them.

So if I work on WCAG 1.3.1 I'd want my collegue to be able to open WCAG 2.1.1 and work on that at the same time. But if one of us presses the "save"-button, all the work of the other person is lost. We hoped you could link to some data structure and have that open in a modal/window something similar and have that person work "save scoped" for just the section they are on, intead of the entire audit. Since this seems to be impossible we cannot use PayloadCMS. But cheer on for you! It's the closest to the dev. experience we've come to love from Sanity that we have found, and it's even open source 🎉

[jmikrut]

Ahhh I got it. Well, we don't have "multiplayer editing" but we did just release a way to create documents from relationship fields, and work separately from the parent document in a modal - similar to what you're asking for here:

You cannot open sections from other collections and work on them.

It might get you what you need! And we will also be shortly building a way to "edit" relationship documents in a separate modal as well. Not sure if this is what you're asking for but I thought I'd bring it to light!

Here's a quick video showing it in action in our demo site:

Screen.Recording.2022-10-12.at.11.57.02.AM.mov

[AndreasJacobsen]

Sorry for the late reply. Work is extremly bussy now with 12 hour 7-days a week days.

What you showed seemed exciting! I'll try it out (once I get some time) and report back. Thank you for taking the time to create a video showing it off ❤️

Just a note on what made me interested in Payload first. It looked like it had tree navigation, which I find useful for audits. It's not how we do audits now but that's just because Sanity dosen't support it.
The arrow next to for example posts when having selected posts indicates that it is the currently selected page. At first we thought this could be used for tree navigation like in Episerver, that sort of navigation and structure is very useful for audits. We could use Episerver but I don't think wrestiling with Epi would be good for my mental health (it is also very, very expensive).
It looks like this. A list of audits expands audits, audits expand audit content.

I'll report back once I've properly tried the modal viewing feature. In the mean time feel free to ask me any accessibility related questions.

[r3pwn]

I know this is more of a minor part of the WCAG, but I recently created a PR (#3011) to address the lack of keyboard focus styles

https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html

I'm also pretty familiar with the WCAG and the various ARIA attributes, and would be happy to help work on making some of the components more accessible.

[wrobson-lllow]

I created a custom select field based off the How to Create a Custom Select Field youtube video.

<div>
        <label className="field-label" htmlFor={`field-${dotToDunder(path)}`}>
          {`${upperCaseFirstLetterAllWords(
            makeSingular(removeDash(tagCollection))
          )}`}
        </label>
          <SelectInput
            path={path}
            name={path}
            options={options}
            value={value}
            onChange={(e) => {
              setValue(e.value);
            }}
          />
      </div>

I was trying to give the label element a "htmlFor" attribute based off the naming schema used for the "SelectInput" component id field-${path} (with "." replaced with "__") however I realized this was an id for a div and a "htmlFor" attribute is only for form components. Thinking it could just be an issue with the custom component, I inspected some other standard payload select fields in other parts of my app and sure enough they were giving the same error:

Incorrect use of <label for=FORM_ELEMENT>