accessibility support

[tristanmkernan]

motivation

to enable the site's access for those who are less accessible.

acceptance criteria

• to achieve WCAG AA compliance for the current iteration of the site
• to document for other developers moving forward how to maintain compliance

etc

i will leave it up to @johnhbenetech to explain the finer details.

i would like to add that the assignee most importantly adds some basic documentation, summarizing what they learned in the process, most helpful resources, anything else they deem necessary.

[bripc]

I created a document with research into the WCAG 2.0 web accessibility standards. It includes definitions and resources, Angular integration articles, and tools for testing the site for WCAG AA compliance.

In summary:

• WCAG is a technical standard with 4 principles and 12 guidelines that each have testable criteria for whether a site is accessible to individuals with disabilities. Each success criteria has a passing level of A, AA, and AAA. The ODK 2.0 Form Builder is aiming for an overall rating of AA.
• Angular has a module called ngAria that will automatically tag the ng directives with ARIA accessibility attributes. See their Developer Guide for accessibility concerns.
• There are a number of tools for testing websites for accessibility, but the one that will view all pages on a site (despite login credentials) in a development environment is a project on GitHub by Paypal called AATT (Automated Accessibility Testing Tool)

[tristanmkernan]

Accessibility with AngularJS

Angular has a module called ngAria that will automatically tag the ng directives with ARIA accessibility attributes. See their Developer Guide for accessibility concerns.

@bripc we're using angular2+, and a brief search did not yield an ngAria equivalent :-(

very cool document! let's get this information added to the readme (or maybe another, linked markdown doc).

did you run any of these testing tools against the current site? i'm not sure that we need AATT (vs a hosted solution) because we really only have one, non-login page on the website. although due to its dynamic nature im not sure 😎

[bripc]

Regarding the Angular2+... I could write a directive (or try to find one online) that basically mimics the Angular 1.X ngAria. ngAria puts ARIA attributes on ng- elements, which could be recreated. If we think that is the best way to go, we can do that. (Potentially it's already "implicitly supported" in Angular 2? Hard to tell from this StackOverflow.)

I think the idea of another linked markdown is better doc because it holds more research to 3rd party information than the current markdown, which is how to deploy the application.

So I did a quick run of one of the WCAG checkers on the current main page. I copied and pasted the generated HTML from the console in the browser into one of the checkers and converted it into a PDF Report. Seems like our biggest issue thus far is just labeling input and other text fields with what they contain/represent.

[tristanmkernan]

@bripc do you want to take a shot at resolving some of the issues in the report?

[bripc]

Yes, I will do that!

[bripc]

I have done more accessibility research in relation to the specifics of this project and made a few small changes based on the accessibility checkers available online, mostly adding titles and labels to existing elements. However, there are lots of things about changing around the actual layout of the application such as headers, changing visual lists of things (such as the buttons on the side) into actual lists, and more. How much should I be changing about the layout at this point? Should I just do as much as possible?

[tristanmkernan]

For anything that in your judgement warrants asking about, please make an issue with your suggestion and we'll work together to fix it! For anything that in your judgement requires no discussion - please make the change and watch the tests :-)

…

On Oct 10, 2017 5:08 PM, "B.P. Cole" ***@***.***> wrote: I have done more accessibility research in relation to the specifics of this project and made a few small changes based on the accessibility checkers available online, mostly adding titles and labels to existing elements. However, there are lots of things about changing around the actual layout of the application such as headers, changing visual lists of things (such as the buttons on the side) into actual lists, and more. How much should I be changing about the layout at this point? Should I just do as much as possible? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQPx1BjqEXuMnPpVOFAKy_z8qSzznbhBks5sq9yvgaJpZM4Pk_IB> .

[tristanmkernan]

@bripc i checked your code changes and noticed that you added a class class when we should be using bootstrap's sr-only class, specifically for hiding content except on screen readers. see more here

https://getbootstrap.com/docs/4.0/getting-started/accessibility/

[bripc]

Oh, great! Thanks for the resource. I'll be sure to use that from now on.

[bripc]

@russon77
For future development, there are a few things that we should keep in mind:

• The accessibility standards warn against "visual lists". The list of options for editing the survey and the prompt type buttons count as "visual lists" so I wrapped the buttons in unordered list markup. For future dev, any lists of options, even button actions, should be wrapped in list markup using the Bootstrap v4 class "list-unstyled" so that no bullet points are added.
• Also, they say that any headers below or of less importance should be in descending size. For example, any elements under an H2 heading should be of H3 size or lower. I changed the current UI to comply with this.

[tristanmkernan]

list of options for editing the survey

do you mean the "properties" section? isn't being a form good enough?

any elements under an H2 heading should be of H3 size or lower

makes sense! 👍

[bripc]

Form is good enough in that area, I meant this visual list:

(This is also what it looks like on my local version, that hasn't been pushed to master yet.)

[tristanmkernan]

@bripc i discovered https://github.com/pa11y/pa11y-ci and configured it to run automatically on travis. while not the end-all solution, i wanted to have some automated tool catching issues moving forward!

[tristanmkernan]

what's really cool is that you can specify a set of actions to run, like adding sections and elements and typing, so we can even write accessibility tests!

[tristanmkernan]

@bripc in order to get the publish flow in action, i resolved the pa11y errors - they were very basic (i can't even tell the difference for the colors)

[tristanmkernan]

lots of relevant tips here: http://fontawesome.io/accessibility/