Screen Reader Audible Output

We need an issue tracker for the performance of screen readers.

Are there any issues with the audible output of the manager?

@paulbohman @kensgists

I haven't had time to look into this in a long time. If someone can set up an instance of the version you want evaluated (to be sure that we have a predictable environment with reproducible results), and give me access, I'll try to set apart some time to look at it. I'm not sure exactly when, but I'll try to fit in my schedule.

On Monday, August 24, 2015, Wayne Roddy notifications@github.com wrote:

We need an issue tracker for the performance of screen readers.

Are there any issues with the audible output of the manager?

@paulbohman https://github.com/paulbohman @kensgists https://github.com/kensgists

— Reply to this email directly or view it on GitHub https://github.com/modxcms/a11y/issues/42.

Paul Bohman

The same cloud is still active. I'll reset your password for you.

I used JAWS, NVDA, and VoiceOver to do a quick review of the interface.

First of all, the interface is certainly much more accessible now than it was in the past. I can tell the team has put in a lot of hard work. Good job. That said, it still has some work to do. I didn't have time to get into a lot of detail, but here are a few things I noticed:

The side navigation doesn't completely worked as expected for screen readers.

Top level items:

It is marked up currently with tab roles on the top level, but tabs require a different kind of construction. Here is a tabpanel constructed according to ARIA specifications: https://dequeuniversity.com/library/aria/tabpanels-accordions/tabpanel
It's ok for a tab panel to be vertical. Here's an example of that: https://dequeuniversity.com/library/aria/tabpanels-accordions/tabbed-accordion
But it's not ok for more than one tab to be selectable at a time. ARIA tabs are supposed to work like radio buttons. You can select only one in the group. You're supposed to use the tab key to arriveat the selected tab in the tablist, and then use the arrow keys to navigate between the tabs within the list.
If you want more than one to be open at a time, you'll have to use something other than a tablist. I recommend using expand/collapse nodes like this: https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-tabless-multiselect-accordion
The most important pieces of markup for the above accordion are:
- aria-expanded, set to true or false.
- Make sure that each node is tabbable (e.g. with tabindex="0")
- role="button" (not tab) on the top level items
- But take a look at the rest of the markup in that example

The second level items

The resource second level of items works differently, with some lists (like resources) acting like a tree (where you can click on the triangle to expand, but on the name to edit) and others (like the elements list) expanding when you click on the name.
If it is going to expand when you click on the name, it can be constructed as described above in my recommendations for the top level items.
- If it is going to give you the choice to expand or edit, depending on where you click, then it needs to work as a tree. Here is an example of an ARIA tree menu: https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/01-introduction.html
- Navigation within a tree menu is done with the arrow keys: right, down, left, up.

Other topics:

Focus management on save (and other similar events)

after saving a document, the focus seems to go to the Link Attributes field for some strange reason. I would probably send the focus first to the popup window ("Please wait...") and then send the focus back to the "Save" button. The success message should be injected into an an aria-live wrapper: Before:
After:
Success! Save Successful
The aria-live wrapper needs to be available in the DOM and empty on page load. It can be hidden from view using the CSS clip method until it is

ready to be shown on the screen.

.visuallyhidden { border: 0; clip: rect(0 0 0 0); height: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute; width: 1px; }
When you're ready to show the message, remove the above styling and then inject the success message into the aria-live region.
After the message fades away visually, remove the text from the aria-live region to leave the wrapper empty again.
You can use the aria-live region to announce other updates too.

The top navigation

The top navigation mostly worked with the keyboard, but moving backward with shift + tab tended to throw it off sometimes, and using a screen reader with it also threw it off. I didn't look at the details as to why that is, but something with the keyboard focus management isn't quite right. Ideally this menu would be constructed with an ARIA menubar and menuitem properties. As with all ARIA widgets, you would tab to the selected menuitem then use the arrow keys to navigate the rest of the items in the menubar and the submenu items. The items with dropdown lists would have the aria-haspopup="true" property. Here's an example of a menubar: http://oaa-accessibility.org/example/26/

Other:

There seems to be some sort of mystery invisible editable item in between the published checkbox and the content field when editing a page. You can get to it by tabbing away from the checkbox. You can even add characters to this field, even though it's invisible.
There are likely other things, but that's what I had time to look at.

On Mon, Aug 24, 2015 at 10:57 AM, Wayne Roddy notifications@github.com wrote:

We need an issue tracker for the performance of screen readers.

Are there any issues with the audible output of the manager?

@paulbohman https://github.com/paulbohman @kensgists https://github.com/kensgists

— Reply to this email directly or view it on GitHub https://github.com/modxcms/a11y/issues/42.

Paul Bohman

Actually, you probably want to use aria-live="assertive" for the success message, rather than aria-live="polite". The assertive message will interrupt the screen reader if it happens to be reading anything at the time, which I think would be appropriate for a success or error message.

On Wed, Aug 26, 2015 at 1:15 AM, Paul Bohman paulbohman@gmail.com wrote:

I used JAWS, NVDA, and VoiceOver to do a quick review of the interface.

First of all, the interface is certainly much more accessible now than it was in the past. I can tell the team has put in a lot of hard work. Good job. That said, it still has some work to do. I didn't have time to get into a lot of detail, but here are a few things I noticed:

The side navigation doesn't completely worked as expected for screen readers.

Top level items:

It is marked up currently with tab roles on the top level, but tabs require a different kind of construction. Here is a tabpanel constructed according to ARIA specifications: https://dequeuniversity.com/library/aria/tabpanels-accordions/tabpanel

It's ok for a tab panel to be vertical. Here's an example of that: https://dequeuniversity.com/library/aria/tabpanels-accordions/tabbed-accordion

But it's not ok for more than one tab to be selectable at a time. ARIA tabs are supposed to work like radio buttons. You can select only one in the group. You're supposed to use the tab key to arriveat the selected tab in the tablist, and then use the arrow keys to navigate between the tabs within the list.

If you want more than one to be open at a time, you'll have to use something other than a tablist. I recommend using expand/collapse nodes like this: https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-tabless-multiselect-accordion

The most important pieces of markup for the above accordion are:

aria-expanded, set to true or false.

Make sure that each node is tabbable (e.g. with tabindex="0")

role="button" (not tab) on the top level items

But take a look at the rest of the markup in that example

The second level items

The resource second level of items works differently, with some lists (like resources) acting like a tree (where you can click on the triangle to expand, but on the name to edit) and others (like the elements list) expanding when you click on the name.

If it is going to expand when you click on the name, it can be constructed as described above in my recommendations for the top level items.

If it is going to give you the choice to expand or edit, depending on where you click, then it needs to work as a tree. Here is an example of an ARIA tree menu: https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/01-introduction.html

Navigation within a tree menu is done with the arrow keys: right, down, left, up.

Other topics:

Focus management on save (and other similar events)

after saving a document, the focus seems to go to the Link Attributes field for some strange reason. I would probably send the focus first to the popup window ("Please wait...") and then send the focus back to the "Save" button. The success message should be injected into an an aria-live wrapper: Before:
After:
Success! Save Successful

The aria-live wrapper needs to be available in the DOM and empty on page load. It can be hidden from view using the CSS clip method until it is

ready to be shown on the screen.

.visuallyhidden { border: 0; clip: rect(0 0 0 0); height: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute; width: 1px; }

When you're ready to show the message, remove the above styling and then inject the success message into the aria-live region.

After the message fades away visually, remove the text from the aria-live region to leave the wrapper empty again.

You can use the aria-live region to announce other updates too.

The top navigation

The top navigation mostly worked with the keyboard, but moving backward with shift + tab tended to throw it off sometimes, and using a screen reader with it also threw it off. I didn't look at the details as to why that is, but something with the keyboard focus management isn't quite right. Ideally this menu would be constructed with an ARIA menubar and menuitem properties. As with all ARIA widgets, you would tab to the selected menuitem then use the arrow keys to navigate the rest of the items in the menubar and the submenu items. The items with dropdown lists would have the aria-haspopup="true" property. Here's an example of a menubar: http://oaa-accessibility.org/example/26/

Other:

There seems to be some sort of mystery invisible editable item in between the published checkbox and the content field when editing a page. You can get to it by tabbing away from the checkbox. You can even add characters to this field, even though it's invisible.

There are likely other things, but that's what I had time to look at.

On Mon, Aug 24, 2015 at 10:57 AM, Wayne Roddy notifications@github.com wrote:

We need an issue tracker for the performance of screen readers.

Are there any issues with the audible output of the manager?

@paulbohman https://github.com/paulbohman @kensgists https://github.com/kensgists

— Reply to this email directly or view it on GitHub https://github.com/modxcms/a11y/issues/42.

Paul Bohman

Paul Bohman

Oh, and one more thing, the menubar example that I gave you ( http://oaa-accessibility.org/example/26/) implements mouseover to expand the menus, but actually I would discourage that. The ARIA model is supposed to act more like desktop applications which are activated with mouse press rather than mouse hover. In fact, that's the whole idea of the ARIA model: to make web applications act like native desktop applications, and to communicate to screen readers through the operating system's accessibility API.

On Wed, Aug 26, 2015 at 1:20 AM, Paul Bohman paulbohman@gmail.com wrote:

Actually, you probably want to use aria-live="assertive" for the success message, rather than aria-live="polite". The assertive message will interrupt the screen reader if it happens to be reading anything at the time, which I think would be appropriate for a success or error message.

On Wed, Aug 26, 2015 at 1:15 AM, Paul Bohman paulbohman@gmail.com wrote:

I used JAWS, NVDA, and VoiceOver to do a quick review of the interface.

First of all, the interface is certainly much more accessible now than it was in the past. I can tell the team has put in a lot of hard work. Good job. That said, it still has some work to do. I didn't have time to get into a lot of detail, but here are a few things I noticed:

The side navigation doesn't completely worked as expected for screen readers.

Top level items:

It is marked up currently with tab roles on the top level, but tabs require a different kind of construction. Here is a tabpanel constructed according to ARIA specifications: https://dequeuniversity.com/library/aria/tabpanels-accordions/tabpanel

It's ok for a tab panel to be vertical. Here's an example of that: https://dequeuniversity.com/library/aria/tabpanels-accordions/tabbed-accordion

But it's not ok for more than one tab to be selectable at a time. ARIA tabs are supposed to work like radio buttons. You can select only one in the group. You're supposed to use the tab key to arriveat the selected tab in the tablist, and then use the arrow keys to navigate between the tabs within the list.

If you want more than one to be open at a time, you'll have to use something other than a tablist. I recommend using expand/collapse nodes like this: https://dequeuniversity.com/library/aria/tabpanels-accordions/sf-tabless-multiselect-accordion

The most important pieces of markup for the above accordion are:

aria-expanded, set to true or false.

Make sure that each node is tabbable (e.g. with tabindex="0")

role="button" (not tab) on the top level items

But take a look at the rest of the markup in that example

The second level items

The resource second level of items works differently, with some lists (like resources) acting like a tree (where you can click on the triangle to expand, but on the name to edit) and others (like the elements list) expanding when you click on the name.

If it is going to expand when you click on the name, it can be constructed as described above in my recommendations for the top level items.

If it is going to give you the choice to expand or edit, depending on where you click, then it needs to work as a tree. Here is an example of an ARIA tree menu: https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/01-introduction.html

Navigation within a tree menu is done with the arrow keys: right, down, left, up.

Other topics:

Focus management on save (and other similar events)

after saving a document, the focus seems to go to the Link Attributes field for some strange reason. I would probably send the focus first to the popup window ("Please wait...") and then send the focus back to the "Save" button. The success message should be injected into an an aria-live wrapper: Before:
After:
Success! Save Successful

The aria-live wrapper needs to be available in the DOM and empty on page load. It can be hidden from view using the CSS clip method until it is

ready to be shown on the screen.

.visuallyhidden { border: 0; clip: rect(0 0 0 0); height: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute; width: 1px; }

When you're ready to show the message, remove the above styling and then inject the success message into the aria-live region.

After the message fades away visually, remove the text from the aria-live region to leave the wrapper empty again.

You can use the aria-live region to announce other updates too.

The top navigation

The top navigation mostly worked with the keyboard, but moving backward with shift + tab tended to throw it off sometimes, and using a screen reader with it also threw it off. I didn't look at the details as to why that is, but something with the keyboard focus management isn't quite right. Ideally this menu would be constructed with an ARIA menubar and menuitem properties. As with all ARIA widgets, you would tab to the selected menuitem then use the arrow keys to navigate the rest of the items in the menubar and the submenu items. The items with dropdown lists would have the aria-haspopup="true" property. Here's an example of a menubar: http://oaa-accessibility.org/example/26/

Other:

There seems to be some sort of mystery invisible editable item in between the published checkbox and the content field when editing a page. You can get to it by tabbing away from the checkbox. You can even add characters to this field, even though it's invisible.

There are likely other things, but that's what I had time to look at.

On Mon, Aug 24, 2015 at 10:57 AM, Wayne Roddy notifications@github.com wrote:

We need an issue tracker for the performance of screen readers.

Are there any issues with the audible output of the manager?

@paulbohman https://github.com/paulbohman @kensgists https://github.com/kensgists

— Reply to this email directly or view it on GitHub https://github.com/modxcms/a11y/issues/42.

Paul Bohman

Paul Bohman

Paul Bohman

Hey Wayne, what's the URL for that instance and do I have a username/password?

Thanks, ken

Ken Petri kennpetri@gmail.com | mobile: 614-218-1499

On Tue, Aug 25, 2015 at 7:13 AM, Wayne Roddy notifications@github.com wrote:

The same cloud is still active. I'll reset your password for you.

— Reply to this email directly or view it on GitHub https://github.com/modxcms/a11y/issues/42#issuecomment-134556554.

modxcms / a11y

Screen Reader Audible Output #42

ready to be shown on the screen.

ready to be shown on the screen.

ready to be shown on the screen.