WCAG 2.0 compliance?

[Ariana French]

Hi all,

Does anyone have insights into whether Omeka is, or will be, aligned to WCAG 2.0 guidelines or reference these guidelines in any way? Can't seem to find any info online (or at omeka.org).

Thank so much!

Ariana

[Megan R. Brett]

Hi Ariana,

Omeka does try to meet W3C web guidelines for accessibility, and we have a Section 508 VPAT available at http://omeka.org/codex/Accessibility_Statement. 

Was there something in particular you were concerned about, in terms of accessibility?

Megan 

[Ariana French]

Hi Megan,

Thanks for the info, much appreciated. Though it's implied in the "W3C standards" statement, I haven't yet seen language that explicitly references WCAG 2.0 guidelines or the levels (A/AA/AAA) that Omeka strives to meet. If that's explicitly stated somewhere, any pointers would be great. 

Otherwise please let me know whether WCAG 2.0 and a specific level of compliance might be in the roadmap. Or, whether Omeka's alignment is more to the Section 508 guidelines.

Thanks for your insights, all the best,

Ariana

[Megan R. Brett]

Hi Ariana,

We tend to align more closely with Section 508 Guidelines; US based public universities often require a Section 508-guided VPAT in order to use Omeka on campus.

Best,

Megan

[Jeremy Boggs]

Hi folks,

Ariana, you seem to be asking a couple of different, but certainly related, questions:

1. Does Omeka meet, or fail to meet, any specific level of WCAG2 guidelines? (or: What is it’s current state?)
2. Does the Omeka project explicitly strive to meet any specific level of WCAG2 guidelines? (or: What is the Omeka project’s thinking, or intent, with regard to WCAG2?)

We can find the answer for the first with relative ease, if you have the tools set up for it. (If you don’t, and are interested, let’s talk more!) I just loaded up a local instead of Omeka 2.0 and ran some accessibility audits on the admin panel using the Accessibility Developer Tools in Chrome [1], the WebAIM extension [2], and the Pa11y CLI [3]. I get a few warnings using the first two, and I get two errors using Pa11y, involving WCAG2 guidelines on form fieldsets. I haven’t run any more tests on additional admin pages, but if my summary of your questions is correct, then yes, Omeka does fail to meet some WCAG2 guidelines.

That said, looking over them, the errors are relatively easy to fix, and I’m pretty confident the fine folks at Omeka are open and willing to address any specific. I know first-hand they’re willing to review and accept pull requests for specific fixes. I believe this is where Megan was thinking when asking you about any specific things you’ve found.

I’m personally interested in the scope, or motives, for your questions. Are you asking to simply gather information? Could you say more about your interest in WCAG2, as a specific set of guidelines? Additionally, are you interested in, or in a position to, do some further testing on Omeka for WCAG compliance? I think its a terrific set of guidelines projects should strive towards. I haven’t tested all of Omeka on WCAG, but regularly test other projects I work on, so have some experience here to help, if you or anyone else is interested in it.

Your question about whether the Omeka project explicitly strives to meet a specific level of WCAG2 is a good one, and is related I think to some of the questions in my previous paragraph. I think it’s also a great question to ask of the Omeka team, for several reasons:

1. If WCAG2 compliance deliberately *isn’t* something considered in Omeka development, it’s useful for outside users and developers to know that, at the very least to not bother to point out specific WCAG errors, but to maybe have a conversation on this list about why it could be beneficial to consider, and make part of the development roadmap.

2. IF WCAG2 compliance *is* something considered in Omeka development, it’s useful to know that, and to be clear about it. That way, I, or maybe even Ariana or any other contributor, would feel more confident in submitting tickets or even sending a pull request addressing a specific WCAG issue. If this is the case, I would suggest updating Omeka’ terrific statement on accessibility to explicitly include WCAG, either at all levels or at a specific level. (As we say on the Scholars’ Lab accessibility statement[4], we try to meet WCAG2 on scholarslab.org and our other projects. We don’t claim that we meet them, but we do say we want to, and strive to, and are open to hearing from anyone who finds specific ways we don’t meet them.)

3. If no one has considered developing Omeka for a specific level of WCAG2 guidelines, I think it would be great to have that conversation, and see how that become part of a development roadmap. Section 508 and WCAG don’t need to be considered exclusively, or seen as separate paths to take in terms of accessible development. It’s possible to develop for both, and that work doesn’t have to fall exclusively on Omeka developers.

Cheers!
Jeremy

[1] https://github.com/GoogleChrome/accessibility-developer-tools-extension
[2] http://wave.webaim.org/extension/
[3] http://pa11y.org
[4] http://scholarslab.org/about/accessibility/

> --
> You received this message because you are subscribed to the Google Groups "Omeka Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to omeka-dev+...@googlegroups.com.
> To post to this group, send email to omek...@googlegroups.com.
> Visit this group at https://groups.google.com/group/omeka-dev.
> For more options, visit https://groups.google.com/d/optout.

[Megan R. Brett]

Hi Ariana and Jeremy,

Regarding Jeremy's point 1: When considering accessibility while developing for Omeka, we are guided by Section 508 standards. We have not, to date, attempted to meet a specific level of WCAG 2.0 compliance. However, we are currently assessing the feasibility of including WCAG evaluation in major updates going forward; if nothing else to acknowledge the errors which may pop up.

In addition, as Jeremy suggests, we are willing to address specific issues which are identified and can be reasonably resolved (without a complete overhaul of the core code or inherent UI of the admin). The best way to report accessibility errors would be to create issues on the github repository for the core, or the theme or plugin causing the error.

Also, we welcome designers and developers to submit WCAG 2.0 and 508 compliant themes and plugins.

Best,

Megan