Ref #17 - initial Accessibility article #141
Conversation
|
|
||
| Dojo 2 is grounded in the belief that accessibility is as important online as it is in our built environments and architects of both share a similar responsibility to provide access to all. Instances of poor accessibility abound in each setting and are very obvious once one starts looking: | ||
|
|
||
| |  | |  | |
There was a problem hiding this comment.
Probably want this image to live inside the dojo.io repo?
|
|
||
| ## Using Dojo 2 widgets | ||
|
|
||
| All widgets provided through the `@dojo/widgets` package have been created with a range of assistive technology and perceptual differences in mind. However, they are not foolproof. There are a number of instances where additional information is required before peak accessibility can be achieved. Often, a few properties are required to enable a widget is to be fully accessible by all users. To help developers achieve this goal, each widget’s example page models best practices. Additionally, many of the properties exposed by a widget are related to accessibility, providing valid values for those properties allows a developer to be sure that they are not missing any a11y enhancements. |
There was a problem hiding this comment.
"to enable a widget is to be fully accessible by all users" -> "to enable a widget to be fully accessible for all users"
|
|
||
| ### Form controls | ||
|
|
||
| All simple form controls, such as `TextInput`, `Textarea`, and `Select`, use either a styled native control or provide a native fallback, which allows them to take advantage of built-in accessibility features wherever possible. Properties are provided in the widget interface to control relevant ARIA (Accessible Rich Internet Applications Suite) attributes like `aria-invalid`, `aria-describedby`, and `aria-readonly`. |
There was a problem hiding this comment.
"which allows them to " replace them with the noun that was intended here
| }); | ||
| ``` | ||
|
|
||
| Would create the following attributes on the input node: |
|
|
||
| All simple form controls, such as `TextInput`, `Textarea`, and `Select`, use either a styled native control or provide a native fallback, which allows them to take advantage of built-in accessibility features wherever possible. Properties are provided in the widget interface to control relevant ARIA (Accessible Rich Internet Applications Suite) attributes like `aria-invalid`, `aria-describedby`, and `aria-readonly`. | ||
|
|
||
| For example, a `TextInput` widget with the following properties: |
There was a problem hiding this comment.
To help with the following sentence, may want to reword this one slightly, e.g. "For example, consider a TextInput widget with the following properties:"
|
|
||
| ### Label | ||
|
|
||
| Most form widgets contain a `label` property that allows users to easily associate a text label with the control along with options to position it or keep it visually hidden. `Label` is also available as a separate widget for use with custom form controls. |
There was a problem hiding this comment.
position it or keep it visually hidden -> replace it with actual noun
|
|
||
| Most form widgets contain a `label` property that allows users to easily associate a text label with the control along with options to position it or keep it visually hidden. `Label` is also available as a separate widget for use with custom form controls. | ||
|
|
||
| The `label` property on both form widgets and the `Label` widget accepts either a string or an [options object](https://github.com/dojo/widgets/blob/master/src/label/Label.ts#L13-17) that allows customization of where the label is placed (before or after the input), and whether it is visually hidden. Visually hiding a label is done by using screen reader-accessible CSS styles to hide text content, and is recommended for use with form controls that have no visible label. |
There was a problem hiding this comment.
visually hidden. Visually hiding (a bit redundant)... perhaps "visually hidden. Screen reader-accessible CSS rules are use to visually hide text content, and is recommended for use with form controls with no visible label"
|
|
||
| Since this example uses a `<button>` element, it requires neither an explicit `tabindex` nor an `onkeydown` event to work properly with a keyboard. Wherever possible, Dojo 2 takes advantage of built-in accessibility by using native elements. However, while native functionality is the most straightforward path to good accessibility, there are times when it is not possible, such as when no built-in element gives the desired functionality. | ||
|
|
||
| For those times, this checklist is a good starting point to ensure that a widget is accessible: |
There was a problem hiding this comment.
"For those times," -> "For those times when native functionality is insufficient,"
| - Make a quick proof-of-concept and try [inspecting its accessibility attributes](http://khan.github.io/tota11y/) in the browser and running through one of the [many](https://medium.com/@addyosmani/accessible-ui-components-for-the-web-39e727101a67) [excellent](http://www-03.ibm.com/able/guidelines/ci162/accessibility_checklist.html) [a11y](https://www.wuhcag.com/wcag-checklist/) [checklists](https://ebay.gitbooks.io/oatmeal/content/). | ||
| - Try operating the widget with only a keyboard and, if possible, a screen reader. | ||
| - If applicable, try turning off your sound. | ||
| - Look at your widget with high contrast mode enabled |
There was a problem hiding this comment.
missing period at the end of this sentence
| - Make a quick proof-of-concept and try [inspecting its accessibility attributes](http://khan.github.io/tota11y/) in the browser and running through one of the [many](https://medium.com/@addyosmani/accessible-ui-components-for-the-web-39e727101a67) [excellent](http://www-03.ibm.com/able/guidelines/ci162/accessibility_checklist.html) [a11y](https://www.wuhcag.com/wcag-checklist/) [checklists](https://ebay.gitbooks.io/oatmeal/content/). | ||
| - Try operating the widget with only a keyboard and, if possible, a screen reader. | ||
| - If applicable, try turning off your sound. | ||
| - Look at your widget with high contrast mode enabled |
There was a problem hiding this comment.
Do we need to end with a conclusion of some sorts? And do we want to mention intern-a11y anywhere in here for helping to test a11y?
There was a problem hiding this comment.
That's a good idea @dylans . Do you have any suggestions on who can help with a section about testing a11y with Intern?
There was a problem hiding this comment.
When in doubt, https://github.com/theintern/intern-a11y/graphs/contributors ... would be @jason0x43.
There was a problem hiding this comment.
Ignore this. I should have reviewed Sarah's version.
One thing to consider...
Do we need to use the term "a11y" for "accessibility" in this article? I don't think there is any benefit in this article and may confuse someone new to accessibility concerns. If we are going to use it, then I think it should be used throughout. The article jumps back and forth between using "a11y" and "accessibility". We don't want to confuse people and make them think they are two different things.
I vote for not using "a11y".
No description provided.