Access the UI with Chrome accessiblity tools

[basham]

See if there are other things missed during development that should be adjusted.

Use Chrome Accessibility tools.

[basham]

The Unspecified label and the disabled buttons don't meet contrast requirements. However:

Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.

http://www.w3.org/TR/WCAG20/#visual-audio-contrast

Therefore, we're fine leaving our disabled button and muted text styles as-is.

[basham]

Found one issue, with how I wrote a for attribute. https://github.com/iuux/adrx-quicknotes/commit/b0d83c4a8d6e48680479f00e6978cca9ca665aa7

[basham]

All other things seem to reasonably pass. No severe failures. Only warnings, mostly related to CKEditor.

[basham]

When opening a dialog:

[Warning] These elements are focusable but either invisible or obscured by another element (23)

Same thing happens when opening the CategorySelector component.

This could maybe be solved by adding an aria-hidden="true" attribute to the window body and a aria-hidden="false" attribute to the dialog. But since the keyboard tab behavior is captured within the dialog, maybe it doesn't really matter? Perhaps this needs to be confirmed by the Assistive Technologies group.

[basham]

http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden

Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.

[basham]

http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/

For browser that include aria-hidden content in the accessibility tree focusable content is included in tab order and is navigable and operable for AT users (as well as other users).

[basham]

http://john.foliot.ca/aria-hidden/

A concern raised by the NVDA team is the question of inheritance, and what happens if an author changes the aria-hidden value of a child element:

<div aria-hidden="true">
  <p aria-hidden="false">Some text here</p>
</div>

Re-reading the spec language, it states:

the element and all of its descendants are not visible

with no other mention, so I would assume that the above is a non-valid anti-pattern. Perhaps some clarity in the spec around this question is required. Further, in conversation with Victor Tsaran (Yahoo!) we could not come up with a reasonable use-case where that might appear – if you can think of one please let us know. The good news is that James Teh from NVDA indicated that they could likely start supporting aria-hidden (in this fashion) without too much effort. Fingers crossed.

[basham]

Both of these examples place dialogs outside of the flow of content. That way the main content area can be hidden, while the dialog is shown. That would solve the iffy inheritance problem, mentioned above.

http://accessibility.athena-ict.com/aria/examples/dialog.shtml

Also, as the dialog is modal we want the rest of the page content (inside div main1) to be removed from the tabbing order. We do that by setting the tabindex of the main content to -1.

http://www.w3.org/WAI/GL/wiki/Using_ARIA_role%3Ddialog_to_implement_a_modal_dialog_box http://www.3needs.org/en/testing/code/role-dialog-code.html

[basham]

Closing this for now, since there are only warnings and nothing severe. Continuing overlay issue in #46.