-
Notifications
You must be signed in to change notification settings - Fork 51
feat(accessibility): Editing/adding behaviors and adding accessibility description for components #74
feat(accessibility): Editing/adding behaviors and adding accessibility description for components #74
Changes from all commits
8ad5ae9
65003f9
7669fd8
83fca4f
0309b1f
96aa2e9
aa73aa5
4031a53
6a08214
f8e00fc
97ad26c
0e4ee5a
9860d3f
bf801d6
eff83f6
472e747
5ec91c4
e252971
641d61a
1c23a5c
237521f
8106bef
c76637c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,11 @@ import HeaderDescription from './HeaderDescription' | |
| * @accessibility | ||
| * Headings communicate the organization of the content on the page. Web browsers, plug-ins, and assistive technologies can use them to provide in-page navigation. | ||
| * Nest headings by their rank (or level). The most important heading has the rank 1 (<h1>), the least important heading rank 6 (<h6>). Headings with an equal or higher rank start a new section, headings with a lower rank start new subsections that are part of the higher ranked section. | ||
| * | ||
| * | ||
| * Other considerations: | ||
| * - when the description property is used in header, readers will narrate both header content and description within the element. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. could you, please, suggest what this is about? Which case we are describing there (actually, would help if you'll be able to share HTML fragment). Thanks!
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| * In addition to that, both will be displayed in the list of headings. | ||
| */ | ||
| class Header extends UIComponent<any, any> { | ||
| static className = 'ui-header' | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,6 +7,16 @@ import { Accessibility } from '../../lib/accessibility/interfaces' | |
|
|
||
| /** | ||
| * An image is a graphic representation of something. | ||
| * @accessibility | ||
| * Default behavior: ImageBehavior | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. just as a matter of thought: for the future we might consider to introduce
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, we can think about that in next PR
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. just a note to consider - in that case we would need to maintain the information about the default behavior in two places - in the comments and in defaultProps.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, but this is something that we have even now, so the situation won't be any different. But this is a very good point raised - probably we should utilize the fact that defaultBehavior is already defined, so that there won't be any chance for these two different places of declaring it to come out os sync at some point |
||
| * - attribute "aria-hidden='true'" is applied on img element, if there is no 'alt' property provided | ||
| * | ||
| * If image should be visible to screen readers, textual representation needs to be provided in 'alt' property. | ||
| * | ||
| * Other considerations: | ||
| * - when alt property is empty, then Narrator in scan mode navigates to image and narrates it as empty paragraph | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 very helpful |
||
| * - when image has role='presentation' then screen readers navigate to the element in scan/virtual mode. To avoid this, the attribute "aria-hidden='true'" is applied by the default image behavior | ||
| * - when alt property is used in combination with aria-label, arialabbeledby or title, additional screen readers verification is needed as each screen reader handles this combination differently. | ||
| */ | ||
| class Image extends UIComponent<any, any> { | ||
| static className = 'ui-image' | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,11 @@ | ||
| import { Accessibility } from '../../interfaces' | ||
|
|
||
| const IconBehavior: Accessibility = (props: any) => ({ | ||
| attributes: { | ||
| root: { | ||
| 'aria-hidden': 'true', | ||
| }, | ||
| }, | ||
| }) | ||
|
|
||
| export default IconBehavior |

There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are really great points. They are concise, easy to understand, and easy to implement. Before merging this, I want to make sure they get first class treatment in the code base.
Here are the thoughts that come to mind when I read the
@accessibilitypoints above:Perhaps we should move these somewhere closer to the Accessibility classes? I can see having these in some kind of requirements JSON file where we could then enforce a test to be written for each one.
Alternatively, we could include these as JSDoc comments directly in the Accessibility classes themselves and parse them out like we do props for components.
I'm not sure
Default behavior: ButtonBehaviormakes sense to doc site users without including docs for the accessibility classes, which might be a great idea.Conclusion
This material is too valuable to leave in component comments alone. We should make it more accessible, put it in the path of updates to keep it fresh, and use it for more cases.
Feedback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend having the separate section on the Docs site for accessibility behaviors, the similar as we have Components section. That section should contain all behaviors and description when and how to use them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, especially once the Accessibility classes will include keyboard handling, we should document them separately.
A lot of this information is however related to the component directly, see especially the 'Other considerations' part:
I agree that at least big part of the documentation should be inside of the Accessibility objects code - we should generate doc pages based on that and link the component page to its default behavior page.
I would prefer this to be done in a separate PR - this PR already includes valuable information to the users. We can improve both the user facing side of it as well as the way how it is generated, but that should be a separate PR.