As a Accessibility responsible, I want to see if the status of the Accessibility check on program item

[tiittapauppi]

Case: Ropecon program 2024 had content warnings and other accessibility information in 460 programs. All of those must be sanity checked by Accessibility team and translations must be done.

Fields ropecon2022_content_warnings and ropecon2023_other_accessibility_information has text which must be checked by a person to make sure that the content is what it is supposed to be and translations are in place.

Accessibilty state drop down field would serve the purpose really well, especially if program items could be filtered by it. First idea of values:

1. Review not required
2. Review required
3. Content reviewed
4. Requires translation
5. Translations ready
6. Accessibility review ready

If it could done so, that if those accessibility related text fields are empty, then the default value would be "Not required" and if either one (or somehow easily configured which fields?) have values, then the state would be by default 2. If someone would later add information on those fields, and the state was 1, the state would change to 2.

[japsu]

This is a prime use case for dimensions in Program V2. While the most prominent use case for dimensions is to offer users ways to filter program (or other things in other modules), the second use case that has been discussed is implementing various workflows.

Kompassi Programme V1 has assumed that every convention could designate every program item as being either

• internal idea,
• asked from program host,
• new,
• accepted,
• published,
• rejected, or
• cancelled.

Obviously, this is not how every event likes to organize their program item workflow, so they need an external place to keep more notes.

We might even have several parallel workflows going on: for example, the program offer to published program workflow indicated above, or the accessibility workflow you indicated in this issue.

In Program V2, I suggest these simply be modelled as dimensions. One dimension may have to be designated "the" workflow dimension that determines when a program is published, but there may be other parallel workflows to it modelled as dimensions.

What we currently lack is the ability to designate some dimensions as internal or private, so that their values would only be shown to those with proper admin rights. Workflow dimensions would likely fall under this category. But they're definitively on the roadmap (in my head).

[japsu]

As to selecting values of dimensions based on fields other than a form field that 1:1 maps into a dimension, I'm not ruling that out, but that's pretty heavy event specific logic that may have to be programmed in, and at that point the feature needed is a facility to put event specific callbacks in.

[japsu]

See also Dimensions in Outline