Evergreen’s Accessibility Context
Evergreen is written in Angular using the ng-bootstrap framework, which is an implementation of Bootstrap. Evergreen therefore inherits most of the accessibility problems present in the frameworks, and it is up to us to work around them. Evergreen also includes some older screens written in AngularJS and Dojo, which may introduce their own accessibility bugs. These screens are in the process of being rewritten in Angular.
Many of the examples and tutorials in Angular, Bootstrap, and ng-bootstrap documentation were not written with accessibility in mind. They frequently use links as event triggers instead of buttons, form fields without labels, CSS-based grids instead of tables, and other violations of accessibility best practices. When working from an example in the documentation, _always_ test it for accessibility before using it in production. Do not trust that the framework documentation is right just because the components are widely used.
The most recent releases of Bootstrap include some disclaimers on accessibility. However, these are neither prominent nor consistent. The Buttons component page, for example, does not mention that many of the default color combinations do not meet Level AA contrast requirements. The tab component’s first accessibility note does not mention that the tab + dropdown combination shown just below it should never be used, because it is not possible to to trigger both the tab change and the dropdown via keyboard controls. This is mentioned in the _second_ accessibility note, in the Javascript section.
Beware! Always test the demo.
In situations where the framework prevents us from writing accessible markup by constraining us to definitions that are wrong, we must file bugs and pull requests with the framework project. For ng-bootstrap, compare the markup to the original Bootstrap component to determine whether the problem was introduced during the conversion to Angular, or was based on an older, incorrect Bootstrap demo.