Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Accessibility review / fixes #129

Open
2 of 12 tasks
joelcollinsdc opened this issue Jun 5, 2017 · 16 comments
Open
2 of 12 tasks

Accessibility review / fixes #129

joelcollinsdc opened this issue Jun 5, 2017 · 16 comments

Comments

@joelcollinsdc
Copy link
Contributor

joelcollinsdc commented Jun 5, 2017 •
edited
Loading

Issue for tracking a11y work. I'm no a11y expert so any advice is much appreciated

Checks

Roughly based on https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility?document_saved=true#Accessibility_testing_checklist

Site Wide

  • Color contrast (using WAVE tool)
  • Eval output of different a11y testers to see if need to use more than one
  • create policy page for a11y

Page Specific

Page Valid HTML No CSS Keyboard Nav Text Alternatives Hidden Content Screen Reader Magnifier
Home Page ✓ ✓ ✓ ✓
Member list ✓ ✓ ✓ ✓
Member list - state ✓ ✓ ✓ ✓
Member detail ✓ ✓ * ✓
Bill list ✓ ✓ ✓ ✓
Bill detail ✓ ✓ ✓ ✓
Voting Record ✓ ✓ ✓ ✓
Committee detail ✓ ✓ ✓ ✓

TODO

  • js charts do not screen read well (ex: sponsorship analysis). Investigate possibilities here.
  • for html validation, skipped moving style tags in body to header. may need to revisit
  • state drop down onchange event. problem?
  • modals - focus on open?
  • fix header style after I made modifications
  • make focused elements more prominent
  • (check) contact modal needs more aria tags?
  • contact modal focus style for list elements very difficult to see with active blue background
  • tab styling needs contrast fixes

Audit tool comparison

I did a quick comparison of various popular accessibility checking tools (https://docs.google.com/spreadsheets/d/1gvtlJsYGpWzGKDAQ7VKKE988QuEirXLQnIuERFXA9rQ/edit?usp=sharing). pa11y (html codesniffer?) seems to have the best coverage and not too many false positives. I preferred the WAVE tool for color contrast issues even though there were a lot of false positives.
@JoshData
Copy link
Member

JoshData commented Jun 7, 2017

That all sounds good.

@JoshData
Copy link
Member

https://dev.to/_bigblind/how-to-make-your-website-accessible-to-people-who-use-a-screen-magnifier

@joelcollinsdc joelcollinsdc mentioned this issue Jun 11, 2017
Merged
@JoshData
Copy link
Member

http://accessibility.umn.edu/tutorials/audit-website-accessibility

@joelcollinsdc
Copy link
Contributor Author

Good resources here. I will try to incorporate into the plan and provide an update.

In the a11y branch I've cleaned up the html for the home page so it reports as being valid now.

@JoshData
Copy link
Member

JoshData commented Jul 5, 2017

Heya. Let me know what's the plan for next steps this month?

@joelcollinsdc
Copy link
Contributor Author

joelcollinsdc commented Jul 6, 2017 via email

@joelcollinsdc
Copy link
Contributor Author

Josh, this is the plan for next steps, hopefully I can get some more of the low hanging fruit checked off this weekend which will leave what I hope will be not too many substantive changes remaining.

  • No css / no js / keyboard nav checks should be pretty quick and I will try to finish this weekend
    • I've done some of the keyboard navigation already, but I had some inconsistent results and wanted to revisit.
  • Identifying non-text content and making sure it has text alternatives
    • Some things jump out at me like the sponsorship analysis chart, this will probably take more time depending on what is found. Hoping this is done early next week.
  • Color contrast
    • I've been seeing a lot of hopefully false positives in the testing tools that I want to get a better sense of before moving on. I'm hoping this is done by late next week.
  • Evaluation with screen reader / high screen magnification
    • Hoping to finish off with actually using a screen reader to run through each page and testing any dynamic content with magnification like it describes in the dev.to article.
  • Policy statement/page

Please let me know if you have any feedback on steps or timing. I'm sort of in the middle of a move so there may be a gap here or there but I am hoping to finish in 2 weeks.

@JoshData
Copy link
Member

JoshData commented Jul 7, 2017 via email

@joelcollinsdc
Copy link
Contributor Author

@JoshData I went through the key pages listed above with styles disabled, and I'm interested in hearing your (or others) opinions on some things... The Mozilla recommendation on css disabling is that the content "makes sense when CSS is turned off". I think the point here is to just not have something like a footer come first in the HTML, so I don't want to be too nitpicking, but I want to do what's best at the same time.

  • When CSS is turned off, tabs are not clickable and do not jump to a tab panel. Tab panels were mostly not associated with a heading so the content within tabs were mostly indiscernible from each other without styling. I added headings to tab panes, but it does appear rather duplicative in a lot of instances. I'm still working on cleaning up the heading styles here. I found "accessible" examples of tabs that both did and did not contain headings in the tab panels so I'm not totally sure on this one. The tabs did seem to all have correct ARIA roles so I'm not sure this will actually trip anyone up.
  • All modals appear the page... I suppose this is expected / normal, not sure anything can be done here
  • The bills listing page is very long because of all the bill subjects. Again, probably not an issue.

@joelcollinsdc
Copy link
Contributor Author

Just wanted to drop some notes that I have been tracking...

  • I'm thinking of either skipping the no js checks or either do a very cursory review. It's not a requirement on MDN and obviously a lot of functionality is missing without it
  • The state drop down on the member listing page has an onchange event which many a11y sites describe as being a bad practice as opposed to using a submit button. I'm still able to navigate the page effectively via keyboard in all modern browsers so I'm curious if the guidance is dated.
  • I've been looking pretty closely at the paypal bootstrap accessibility plugin. There are certain elements of it that seem compelling, but I'm concerned about the lack of activity around it. A particular feature that seemed like a good idea was the auto focusing of modal windows (and returning focus when modal closes) but according to the bootstrap docs modals should be accessible regardless. The dev.to link you referenced above particularly points out the issues of having modals pop up far away from the button that triggered them and the issues around that...

@JoshData
Copy link
Member

When CSS is turned off, tabs are not clickable and do not jump to a tab panel.

Interesting. I tried one page in the links browser and tabs worked. I'm not sure how much CSS/JS links recgonizes, if any. I think that'd be good to fix but I'm not sure why it doesn't work. I thought that href="#thing" normally scrolls automatically to an element with id="thing".

I found "accessible" examples of tabs that both did and did not contain headings in the tab panels so I'm not totally sure on this one.

Seems reasonable to put this off until you try the site with a screen reader and see what that experience is like.

All modals appear the page... I suppose this is expected / normal, not sure anything can be done here

Not sure either.

I think we can expect people to have CSS working since modern accessibility tools probably work on top of CSS. But I dunno.

I'm thinking of either skipping the no js checks

Yeah the whole site relies on JS so we can just assume it's enabled (if that's what you mean).

The state drop down on the member listing page has an onchange event which many a11y sites describe as being a bad practice as opposed to using a submit button

Yeah I dunno either.

The dev.to link you referenced above particularly points out the issues of having modals pop up far away from the button that triggered them

Did you notice that we did that anywhere? I couldn't think of anything off hand when I posted it.

@joelcollinsdc
Copy link
Contributor Author

I reviewed the site with a person that has accessibility needs pertaining to visual acuity and contrast and got a lot of good feedback. These are the raw notes from that session. No screen reader or other accessibility tools were used, just magnification.

Home page

  • the background image made discerning lots of things apart on the home page difficult
  • placeholder text on search box: unable to read
  • recommendation: more clearly outline the search box, especially when active
  • nav menu on home page not easy to see. when hovering, much better

Members of Congress

  • darker outline on search box

State Page

  • Tabs were a common source of confusion. Unable to determine content was hidden behind tabs, and unable to tell which tab was current other than different mouse cursor
  • The hover color for a tab was not contrasted enough to be discerned. Was able to tell it was a tab though because of the cursor.
  • [general] a comment was made about red link text being difficult for people with albinism

Member Page

  • for the modal popups, even though sometimes the popup was not immediately visible, the darkened background was enough of an indication that something happened
    • for the contact popup, there was some confusion when a option was selected as the new questions that popped in were not immediately obvious
    • the "visit donald beyer" button was hard to read (green/white text)

Sponsorship analysis chart

*the hover popups on each dot made the legend difficult to read as they were being covered up

Key votes

  • could not see contrast on yea/nea column

MIssed votes

  • good that there is text alternative
  • chart legend appeared jumbled & sideways text was difficult to read

[general] for interior pages, the active tab and hover color is very close and difficult to discern
[general] the site notice below nav was difficult to read but was possible

Bills & Resolutions

  • standard issues with tabs

Bill Page

  • unable to see the emoji
  • they greyed out next steps for a bill (that havent happened yet) were unable to be read. This may cause problems with a screen reader, too

Voting Record

  • good contrast on the drop down menu in the sidebar. check for differences here with others

Vote Page

  • Both images were difficult to understand the meaning of them. Alt/title text / alternative text?

Committee Page

  • The green buttons with white text here were easier to read. look at differences with the ones on the member page.

@joelcollinsdc
Copy link
Contributor Author

Josh, I pushed up some changes for text alternatives, I think it would be good to stop here and do a status check on how much more we would like to pursue for this effort. Merging into master to incorporate your recent changes would be a good move as well as it looks like there have been a lot of positive changes to the home page.

A lot of the remaining items are things that seem to come directly from bootstrap (like, tabs and modals), which is making me question the validity and the utility of focusing on them here versus seeing if they will be fixed upstream. For tabs, I began adding duplicate headers to the major tabs to reiterate page structure. Paypal has a bootstrap plugin that adds some niceties to bootstrap modals that does things like auto focusing on the modal window, but development on it seems to have stagnated.

Long story short, I think we should sync this up with master and re-evaluate where we are at. Thanks!

@JoshData
Copy link
Member

JoshData commented Aug 2, 2017

Hey. Great. I'm happy with the progress made so far on correcting markup issues and missing headings and things and agree that we should probably put off things that can be fixed at the framework level. Your review with the user with accessibility needs is great and probably where future effort should go.

As you probably saw, I merged master into the branch, with a new homepage layout that hopefully improves the accessibility of that page especially with the background image problems.

Fyi, I plan to deploy the cloud_deployment branch whenever the Senate goes on recess, so probably in two weeks.

@joelcollinsdc
Copy link
Contributor Author

@JoshData my new job is proving to take up more time than I was expecting and I really don't have the capacity to work on this anymore. I think a lot of the work that is left involves CSS as well which isn't my strongest area. Is there a way I can help transition any remaining work to someone else?

@JoshData
Copy link
Member

Heya. No worries. Your PR is deployed now, and your user review notes will be very helpful, so this is a fine stopping point. Thanks for your work on it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@joelcollinsdc @JoshData