Is there an issue describing what you intend for this PR? I can't seem to find one.

This is a pretty large change to testing requirements. Let's talk about it in a dev meeting.

Hey Tim! Yeah, I accidentally made the issue in the website repo by accident, so I'll remake them over here now.

I'm not sure what you mean in terms of additional testing requirements. My assumption is that we are aiming for a fully accessible app. This adds one more layer to help stop regressions of already fixed tickets or introduction of new inaccessible code on already accessible components. Similar to other tests in the suite, this may slow things down in the short term, but will expedite long term development by eliminating tech debt and future untangling of inaccessible code.

@milofultz Great, thanks for adding that issue! I'm not involved in the website project, so I haven't been following conversations there.

I took a closer look at the code, and it's all smart. Your keen eye has identified an issue, and come up with a good solution. It just pushes established standards a bit and I want to make sure we are all clear on what the standards are. Outside of the standards discussion, I'm good with approving it.

Changes to Testing and Accessibility Standards

We're trying to thread a needle with development requirements. We want to set requirements that are achievable by volunteers with relatively little coding experience, but our standards should still result in an app that stably behaves for our target user base.

The target behavior and user base have changed over time, but my general idea is we want to reliably serve a person whose only access is via a computer provided to them by a public library. We try to simplify this to: all app features must function in the most recent version of the chromium web browser.

Fully Accessible Apps

I think what I'm looking for is a definition of a "fully accessible app". To me, I've always understood it as "accessibility to some degree." A trivial (but common) example: our software will not be accessible to someone who does not have access to the world wide web, or a web browser. There's no way around this while still keeping our SoLiD architecture.

People with color blindness don't use screen readers, android-exclusive apps are not accessible to people with IPhones, etc...

I'm 100% in favor of improving accessibility on this app, I just want to document what those accessibility standards are.

I'm also ok with breaking work on a feature into several PRs to meet a high standard. Again, we just need to document what those standards are so we can know what the progression of PRs should be.

Hey @milofultz, just wondering if you have any updates on this

Hey @milofultz, just wondering if you have any updates on this

Hi @andycwilliams , I've had a bunch of other things come up that require my attention, so I can't put any effort towards this in the foreseeable future.

As to @timbot1789 's comments, I did not address them (even though I thought I did in a real Mandela moment 😅 ), so I'll document my thoughts here for the next person who can take this on.

I think what I'm looking for is a definition of a "fully accessible app". To me, I've always understood it as "accessibility to some degree." A trivial (but common) example: our software will not be accessible to someone who does not have access to the world wide web, or a web browser.

First, I should clarify that accessibility means web accessibility, in this instance. If someone does not have access to the web, then none of this matters since the page won't load anyway 🙃 .

The industry standard for an accessible website falls within the guidelines set by WCAG. There are many standards, ranging from A-AAA, which is minimally to maximally accessible. WCAG 2.2 is the most recent version and all axe scanners are using this standard as their baseline.

While axe and other automated tools can't (and shouldn't be relied on to) catch all accessibility errors, it can at least help enforce some of the rules and present them as errors early on in the development lifecycle when the errors are more trivial to fix. This can be ratcheted down to a lower threshold of accessibility (e.g. A, see the available options), but it is recommended to set it maximally. The benefits to this are that you can identify what exists and temporarily ignore those violations, allowing tickets to be created and remediated, and you can really quickly identify newly introduced issues early on in new development.

This allows pivoting to more accessible solutions earlier than later. All tech debt is debt, but accessibility tech debt is notoriously difficult to deal with, as it touches and is reliant on the interaction of engineering, design, many cohorts of users, etc. We are currently doing this at my job and it's taking many dedicated teams for every product over a year just to get everything to a barely passable WCAG A level.

I think this particular project should have a particularly higher level of accessibility than just WCAG A, as it is looking to be used within governmental organizations. It is important to note that for an application to be used in any government capacity, it must meet Section 508, which directly references WCAG AA rules as it's criteria. If you aim for a WCAG AAA app, it might feel really overkill, but it is always easier to compromise a bit down to AA than it is to try and make an A page into a AA.

We're trying to thread a needle with development requirements. We want to set requirements that are achievable by volunteers with relatively little coding experience, but our standards should still result in an app that stably behaves for our target user base.

I understand and appreciate the limitations that exist with a volunteer project. But with regards to the limitations that exist with the eventual guidelines that this will run into (government accessibility), I think there is not really a choice to be made. If all the volunteers work their asses off on an app that United States governments literally cannot legally use, then the work is for nothing.

Luckily, the accessibility testing that is looking to be added here gives links to pages that contain extensive resources for what you can do to make something accessible. Through this and the deeper explanations from W3C, WCAG, and various great people and their blogs, developers can gain this education in real time and implement it directly.

Think about this the same as you would security. Would the project allow security be compromised to make it easier for volunteers to work on the project? I think it would be expected for volunteers to go and spend time learning about how to make a secure experience for users before implementing it in the application. Part of this is legal to cover our respective asses, but also because no government would touch an application that can't go through the rigor of a security audit and come out clean. This is the same experience that an application would go through with accessibility (including the litigation element).

People with color blindness don't use screen readers, android-exclusive apps are not accessible to people with IPhones, etc...

As an aside, know that disabilities are not singular and intersect in ways that are difficult to predict. Colorblindness might not require a screen reader to use a given webpage, but what about a colorblind person with declining motor skills that cannot type or use their mouse, or has a cognitive impairment, or has low vision but is not blind, etc. The reason for the above WCAG guidelines is so that we don't have to know every intersection or cohort ourselves. We can rely on those guidelines so that it will give everyone the best possible experience based on our current body of knowledge.

@milofultz Thank you for your response. I assure you, I am well aware of these accessibility guidelines. I have worked with them extensively before, personally and professionally. I was seeking a specific standard that you were looking to implement, which you gave here:

for an application to be used in any government capacity, it must meet Section 508, which directly references WCAG AA rules as it's criteria.

That is an important consideration, and one that we will need to discuss as a group. It's a project level decision what accessibility guidelines we follow, and we at the very least need to make sure everyone on the project is aware of them. A single PR by a single developer does not make for a good communication forum.

If you are willing to spearhead a push for improved accessibility, please bring this topic to a dev meeting.

Unfortunately, this PR is falling behind the dev branch, and will require some work to bring back up to date. This has also stayed in review with little movement for several months. If you're able to get it back up to date by this time next week (Tuesday, April 16), we can continue reviewing it. If not, we will close the PR. After that, you may open a new PR from this branch if you choose.