search

CodeAllianceOrg / odk2

Visual, web-based form builder application for ODK 2.0
http://odk-form-builder.surge.sh/
GNU General Public License v3.0
1 stars 1 forks source link

accessibility support #7

Open tristanmkernan opened 7 years ago

tristanmkernan commented 7 years ago

motivation

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

acceptance criteria

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 commented 7 years ago

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:

tristanmkernan commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

bripc commented 7 years ago

Yes, I will do that!

bripc commented 7 years ago

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 commented 7 years ago

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" notifications@github.com 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 https://github.com/CodeAllianceOrg/odk2/issues/7#issuecomment-335608544, or mute the thread https://github.com/notifications/unsubscribe-auth/AQPx1BjqEXuMnPpVOFAKy_z8qSzznbhBks5sq9yvgaJpZM4Pk_IB .

tristanmkernan commented 7 years ago

@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 commented 7 years ago

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

bripc commented 7 years ago

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

tristanmkernan commented 7 years ago

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 commented 7 years ago

Form is good enough in that area, I meant this visual list: screen shot 2017-10-17 at 2 38 51 pm (This is also what it looks like on my local version, that hasn't been pushed to master yet.)

tristanmkernan commented 7 years ago

@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 commented 7 years ago

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 commented 6 years ago

@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 commented 6 years ago

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