Question: Key Operation of Dropdown menu

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Question: Key Operation of Dropdown menu

Tanaka, Satoko

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Bryan Garaventa

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [mailto:[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Tanaka, Satoko

Hi Bryan,

 

Thank you so much for the detailed explanation.

Especially this example is very helpful for me.

http://whatsock.com/test/ARIA%20Menubar/menubar.html

 

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 3:04 PM
To: Tanaka, Satoko/
田中 智子; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <
[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Jonathan Avila-2
In reply to this post by Bryan Garaventa

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [mailto:[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Tanaka, Satoko

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [mailto:[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Jonathan Avila-2

Ø  Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

 

Yes, in general non-alphanumeric keystrokes such as pressing the arrow keys on a keyboard are not sent through to the web page on mobile Safari.

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer
SSB BART Group
[hidden email]

703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Tanaka, Satoko [mailto:[hidden email]]
Sent: Wednesday, July 20, 2016 8:55 PM
To: Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Tanaka, Satoko

Hi Jonathan,

 

It’s good to know. Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [mailto:[hidden email]]
Sent: Thursday, July 21, 2016 10:00 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Ø  Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

 

Yes, in general non-alphanumeric keystrokes such as pressing the arrow keys on a keyboard are not sent through to the web page on mobile Safari.

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer
SSB BART Group
[hidden email]

703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 8:55 PM
To: Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Bryan Garaventa
In reply to this post by Tanaka, Satoko

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [mailto:[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Tanaka, Satoko

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [mailto:[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Bryan Garaventa

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [mailto:[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Tanaka, Satoko

That’s great. Thank you for the explanation, Bryan. Much appreciated!

If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [mailto:[hidden email]]
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Sean Murphy (seanmmur)

What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.

 

Sean Murphy

 

From: Tanaka, Satoko [mailto:[hidden email]]
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

That’s great. Thank you for the explanation, Bryan. Much appreciated!

If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Cohn, Jonathan

VoiceOver also has no issues with multibyte. One does have to make  sure the lang attribute is set correctly in the HTML.

 

Over the weekend, I read an article from a Korean  company where even though the specific page was in English, VoiceOver (on IOS) started reading it in Korean.

 

 

From: Sean Murphy (seanmmur) [mailto:[hidden email]]
Sent: Monday, July 25, 2016 2:23 AM
To: Tanaka, Satoko <[hidden email]>; Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.

 

Sean Murphy

 

From: Tanaka, Satoko [[hidden email]]
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

That’s great. Thank you for the explanation, Bryan. Much appreciated!

If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Tanaka, Satoko

Thank you, Murphy and Jonathan. Those information are very helpful.

I have no specific question about multi-byte environment. I just want to know something new for me, if someone has useful information and knowledge about screen readers on multi-byte environment. Thank you for sharing your knowledge. it is so helpful.

 

Many thanks and kind regards,

Satoko

 

From: Cohn, Jonathan [mailto:[hidden email]]
Sent: Tuesday, July 26, 2016 12:16 AM
To: Sean Murphy (seanmmur); Tanaka, Satoko/
田中 智子; Bryan Garaventa; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

VoiceOver also has no issues with multibyte. One does have to make  sure the lang attribute is set correctly in the HTML.

 

Over the weekend, I read an article from a Korean  company where even though the specific page was in English, VoiceOver (on IOS) started reading it in Korean.

 

 

 

From: Sean Murphy (seanmmur) [[hidden email]]
Sent: Monday, July 25, 2016 2:23 AM
To: Tanaka, Satoko <[hidden email]>; Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.

 

Sean Murphy

 

From: Tanaka, Satoko [[hidden email]]
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

That’s great. Thank you for the explanation, Bryan. Much appreciated!

If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Sean Murphy (seanmmur)

Satoko

 

Jaws for Japanese web site:

http://www.extra.co.jp/jaws/index.html

 

NVDA Japanese site:

https://www.nvda.jp/en/

 

 

Refer to the above two windows screen reader’s site for more information.

 

Sean Murphy

Accessibility Software engineer

[hidden email]

Tel: +61 2 8446 7751      Cisco Systems, Inc.

The Forum 201 Pacific Highway

ST LEONARDS

2065

Australia

cisco.com          

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

 

From: Tanaka, Satoko [mailto:[hidden email]]
Sent: Tuesday, 26 July 2016 9:35 AM
To: Cohn, Jonathan <[hidden email]>; Sean Murphy (seanmmur) <[hidden email]>; Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Thank you, Murphy and Jonathan. Those information are very helpful.

I have no specific question about multi-byte environment. I just want to know something new for me, if someone has useful information and knowledge about screen readers on multi-byte environment. Thank you for sharing your knowledge. it is so helpful.

 

Many thanks and kind regards,

Satoko

 

From: Cohn, Jonathan [[hidden email]]
Sent: Tuesday, July 26, 2016 12:16 AM
To: Sean Murphy (seanmmur); Tanaka, Satoko/
田中 智子; Bryan Garaventa; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

VoiceOver also has no issues with multibyte. One does have to make  sure the lang attribute is set correctly in the HTML.

 

Over the weekend, I read an article from a Korean  company where even though the specific page was in English, VoiceOver (on IOS) started reading it in Korean.

 

 

 

From: Sean Murphy (seanmmur) [[hidden email]]
Sent: Monday, July 25, 2016 2:23 AM
To: Tanaka, Satoko <[hidden email]>; Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.

 

Sean Murphy

 

From: Tanaka, Satoko [[hidden email]]
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

That’s great. Thank you for the explanation, Bryan. Much appreciated!

If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

RE: Question: Key Operation of Dropdown menu

Tanaka, Satoko

Thank you Murphy. It’s helpful. I’ll check them later.

 

Many thanks and kind regards,

Satoko

 

From: Sean Murphy (seanmmur) [mailto:[hidden email]]
Sent: Tuesday, July 26, 2016 9:08 AM
To: Tanaka, Satoko/
田中 智子; Cohn, Jonathan; Bryan Garaventa; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko

 

Jaws for Japanese web site:

http://www.extra.co.jp/jaws/index.html

 

NVDA Japanese site:

https://www.nvda.jp/en/

 

 

Refer to the above two windows screen reader’s site for more information.

 

Sean Murphy

Accessibility Software engineer

[hidden email]

Tel: +61 2 8446 7751      Cisco Systems, Inc.

The Forum 201 Pacific Highway

ST LEONARDS

2065

Australia

cisco.com          

 

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, 26 July 2016 9:35 AM
To: Cohn, Jonathan <[hidden email]>; Sean Murphy (seanmmur) <[hidden email]>; Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Thank you, Murphy and Jonathan. Those information are very helpful.

I have no specific question about multi-byte environment. I just want to know something new for me, if someone has useful information and knowledge about screen readers on multi-byte environment. Thank you for sharing your knowledge. it is so helpful.

 

Many thanks and kind regards,

Satoko

 

From: Cohn, Jonathan [[hidden email]]
Sent: Tuesday, July 26, 2016 12:16 AM
To: Sean Murphy (seanmmur); Tanaka, Satoko/
田中 智子; Bryan Garaventa; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

VoiceOver also has no issues with multibyte. One does have to make  sure the lang attribute is set correctly in the HTML.

 

Over the weekend, I read an article from a Korean  company where even though the specific page was in English, VoiceOver (on IOS) started reading it in Korean.

 

 

 

From: Sean Murphy (seanmmur) [[hidden email]]
Sent: Monday, July 25, 2016 2:23 AM
To: Tanaka, Satoko <[hidden email]>; Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.

 

Sean Murphy

 

From: Tanaka, Satoko [[hidden email]]
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

That’s great. Thank you for the explanation, Bryan. Much appreciated!

If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 

Reply | Threaded
Open this post in threaded view
|

multibyte content (was: Question: Key Operation of Dropdown menu)

Christophe Strobbe-2
In reply to this post by Cohn, Jonathan

On 25/07/2016 17:16, Cohn, Jonathan wrote:

VoiceOver also has no issues with multibyte. One does have to make  sure the lang attribute is set correctly in the HTML.


Setting the lang attribute correctly is good advice, but is it sufficient?
One issue that I encounter rather frequently is that pages that use multi-byte content are still sent over the network as Windows-1252 or a variant of ISO/IEC 8859. On the user side, this can usually be fixed by choosing a different encoding in the browser (e.g. "More tools ..." > "Encoding" in Chrome's hamburger menu), but most non-technical users don't know about this feature. In some cases, even changing to a different encoding won't help. I assume this is because both the document encoding and the server's HTTP charset parameter are incorrect. (See <https://www.w3.org/International/articles/http-charset/index>.)

Best regards,

Christophe

 

Over the weekend, I read an article from a Korean  company where even though the specific page was in English, VoiceOver (on IOS) started reading it in Korean.

 

 

From: Sean Murphy (seanmmur) [[hidden email]]
Sent: Monday, July 25, 2016 2:23 AM
To: Tanaka, Satoko [hidden email]; Bryan Garaventa [hidden email]; Jonathan Avila [hidden email]; WAI IG [hidden email]
Subject: RE: Question: Key Operation of Dropdown menu

 

What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.

 

Sean Murphy

 

From: Tanaka, Satoko [[hidden email]]
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

That’s great. Thank you for the explanation, Bryan. Much appreciated!

If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.

 

There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Bryan,

 

Thank you so much for the information. It is actually helpful.

Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?

 

Many thanks and kind regards,

Satoko

 

From: Bryan Garaventa [[hidden email]]
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Satoko,

It may be helpful to read the screen reader sections at

http://whatsock.com/training/#hd32

 

This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi Jonathan,

 

Thank you for summarizing the key points. It makes sense for me.

The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?

It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.

 

Many thanks and kind regards,

Satoko

 

From: Jonathan Avila [[hidden email]]
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 

 

Jonathan

 

Jonathan Avila

Chief Accessibility Officer

SSB BART Group 

[hidden email]

703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 

From: Bryan Garaventa [[hidden email]]
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu

 

Hi,

In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.

 

The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.

E.G

http://whatsock.com/training/matrices/#menubar

and

http://whatsock.com/training/matrices/#menu

 

To visually see these roles in action, try using Visual ARIA at

                                http://whatsock.com/training/matrices/visual-aria.htm

 

When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.

 

The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:

https://github.com/accdc/aria-menubar

 

                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.

 

Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.

 

All the best,

Bryan

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

[hidden email]

415.624.2709 (o)

www.SSBBartGroup.com

 

From: Tanaka, Satoko [[hidden email]]
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu

 

Hi,

 

I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.

 

https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html

In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.

When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.

To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.

 

I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.

 

My question is:

Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)

In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?

 

I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.

 

 

Many thanks and kind regards,

Satoko

 



-- 
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749

“I drink tea and I know things.” 
Falsely attributed to Christophe Lannister.
Reply | Threaded
Open this post in threaded view
|

Re: multibyte content (was: Question: Key Operation of Dropdown menu)

Olaf Drümmer
Wouldn’t one want to be using UTF-8 all the time anyway?

Olaf


On 04.08.2016, at 11:50, Christophe Strobbe <[hidden email]> wrote:


On 25/07/2016 17:16, Cohn, Jonathan wrote:
VoiceOver also has no issues with multibyte. One does have to make  sure the lang attribute is set correctly in the HTML.

Setting the lang attribute correctly is good advice, but is it sufficient?
One issue that I encounter rather frequently is that pages that use multi-byte content are still sent over the network as Windows-1252 or a variant of ISO/IEC 8859. On the user side, this can usually be fixed by choosing a different encoding in the browser (e.g. "More tools ..." > "Encoding" in Chrome's hamburger menu), but most non-technical users don't know about this feature. In some cases, even changing to a different encoding won't help. I assume this is because both the document encoding and the server's HTTP charset parameter are incorrect. (See <https://www.w3.org/International/articles/http-charset/index>.)

Best regards,

Christophe 

 
Over the weekend, I read an article from a Korean  company where even though the specific page was in English, VoiceOver (on IOS) started reading it in Korean. 
 
 
From: Sean Murphy (seanmmur) [[hidden email]] 
Sent: Monday, July 25, 2016 2:23 AM
To: Tanaka, Satoko [hidden email]; Bryan Garaventa [hidden email]; Jonathan Avila[hidden email]; WAI IG [hidden email]
Subject: RE: Question: Key Operation of Dropdown menu
 
What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.
 
Sean Murphy
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu
 
That’s great. Thank you for the explanation, Bryan. Much appreciated!
If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!
 
Many thanks and kind regards,
Satoko
 
From: Bryan Garaventa [[hidden email]] 
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.
 
There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.
 
All the best,
Bryan
 
 
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi Bryan,
 
Thank you so much for the information. It is actually helpful.
Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?
 
Many thanks and kind regards,
Satoko
 
From: Bryan Garaventa [[hidden email]] 
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi Satoko,
It may be helpful to read the screen reader sections at
 
This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.
 
All the best,
Bryan
 
 
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi Jonathan,
 
Thank you for summarizing the key points. It makes sense for me.
The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?
It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.
 
Many thanks and kind regards,
Satoko
 
From: Jonathan Avila [[hidden email]] 
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 
 
Jonathan
 
Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 
From: Bryan Garaventa [[hidden email]] 
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi,
In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.
 
The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.
E.G
and
 
To visually see these roles in action, try using Visual ARIA at
                                http://whatsock.com/training/matrices/visual-aria.htm
 
When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.
 
The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:
 
                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.
 
Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.
 
All the best,
Bryan
 
 
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu
 
Hi,
 
I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.
 
In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.
When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.
To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.
 
I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.
 
My question is:
Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)
In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?
 
I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.
 
 
Many thanks and kind regards,
Satoko
 


-- 
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749

“I drink tea and I know things.” 
Falsely attributed to Christophe Lannister.

Reply | Threaded
Open this post in threaded view
|

Re: multibyte content

Christophe Strobbe-2

On 4/08/2016 12:37, Olaf Drümmer wrote:
Wouldn’t one want to be using UTF-8 all the time anyway?

Yet, that's what I do, but some web content authors don't use the right configurations for their tools.
Possibly, some authors publish their content on a server where they can't change the HTTP charset parameter for UTF-8.

Best regards,

Christophe


Olaf


On 04.08.2016, at 11:50, Christophe Strobbe <[hidden email]> wrote:


On 25/07/2016 17:16, Cohn, Jonathan wrote:
VoiceOver also has no issues with multibyte. One does have to make  sure the lang attribute is set correctly in the HTML.

Setting the lang attribute correctly is good advice, but is it sufficient?
One issue that I encounter rather frequently is that pages that use multi-byte content are still sent over the network as Windows-1252 or a variant of ISO/IEC 8859. On the user side, this can usually be fixed by choosing a different encoding in the browser (e.g. "More tools ..." > "Encoding" in Chrome's hamburger menu), but most non-technical users don't know about this feature. In some cases, even changing to a different encoding won't help. I assume this is because both the document encoding and the server's HTTP charset parameter are incorrect. (See <https://www.w3.org/International/articles/http-charset/index>.)

Best regards,

Christophe 

 
Over the weekend, I read an article from a Korean  company where even though the specific page was in English, VoiceOver (on IOS) started reading it in Korean. 
 
 
From: Sean Murphy (seanmmur) [[hidden email]] 
Sent: Monday, July 25, 2016 2:23 AM
To: Tanaka, Satoko [hidden email]; Bryan Garaventa [hidden email]; Jonathan Avila[hidden email]; WAI IG [hidden email]
Subject: RE: Question: Key Operation of Dropdown menu
 
What specific questions do you have in relation to screen reader support with multi-byte language screen reader’s? As I know Jaws for Windows does support Japanese and believe other Asian languages as well. I suspect Voice-Over also does and haven’t looked into it.
 
Sean Murphy
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Friday, 22 July 2016 5:29 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu
 
That’s great. Thank you for the explanation, Bryan. Much appreciated!
If someone knows about screen reader’s behaviors on multi-byte-language environments, any comments and advices would be appreciated. J Thank you!
 
Many thanks and kind regards,
Satoko
 
From: Bryan Garaventa [[hidden email]] 
Sent: Friday, July 22, 2016 4:11 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
When I wrote these articles I was using the English versions of these programs, however the underlying functionality would be the same regardless. For example, the way that VoiceOver works by touch is the same in English as it is when using any other language that iOS supports, as well as for JAWS and all of the languages that it supports on Windows, and so on.
 
There might be some differences in some languages that use right to left language displays, but the input and output of the base platforms should remain consistent. Others here may be able to elaborate more on how this works in the background for Japanese and Chinese language interaction models though.
 
All the best,
Bryan
 
 
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Thursday, July 21, 2016 11:03 PM
To: Bryan Garaventa <[hidden email]>; Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi Bryan,
 
Thank you so much for the information. It is actually helpful.
Are these articles about English version of screen readers? I mean, do you know whether there are any differences in their behaviors between English environment and other environment, such as Japanese and Chines?
 
Many thanks and kind regards,
Satoko
 
From: Bryan Garaventa [[hidden email]] 
Sent: Friday, July 22, 2016 1:30 PM
To: Tanaka, Satoko/
田中 智子; Jonathan Avila; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi Satoko,
It may be helpful to read the screen reader sections at
 
This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS and how these screen readers differ with regard to interaction and accessibility.
 
All the best,
Bryan
 
 
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Wednesday, July 20, 2016 5:55 PM
To: Jonathan Avila <[hidden email]>; WAI IG <[hidden email]>
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi Jonathan,
 
Thank you for summarizing the key points. It makes sense for me.
The last part of your comment, I cannot understand clearly the situation of Safari on mobile. Do you mean mobile version of Safari does not recognize keyboard connection, which means users cannot operate the mobile Safari with keyboard?
It seems I should learn more about mobile accessibility. If you would kindly explain more details, it would be highly appreciated. Thanks in advance.
 
Many thanks and kind regards,
Satoko
 
From: Jonathan Avila [[hidden email]] 
Sent: Wednesday, July 20, 2016 10:52 PM
To: WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
Satoko, in short it think what Bryan is getting at is it’s ok to rely on arrow keys for desktop as long as the proper ARIA roles are there that would allow these keys to be sent from desktop screen readers and would be assumed by the user based on the appropriate roles.  If the appropriate roles are not used use of only arrow keys would likely not be available to desktop screen reader users and may not be apparent for use even if the user was an advanced screen reader user.  On mobile you will likely have a different situation as some browsers like Safari do not pass keystrokes through from the keyboard to the web page. 
 
Jonathan
 
Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
703.637.8957 (Office)

 

Visit us online: Website | Twitter | Facebook | Linkedin | Blog

Check out our Digital Accessibility Webinars!

 
From: Bryan Garaventa [[hidden email]] 
Sent: Wednesday, July 20, 2016 2:04 AM
To: Tanaka, Satoko; WAI IG
Subject: RE: Question: Key Operation of Dropdown menu
 
Hi,
In looking at the code shown on that page, it looks like the only roles present are role=menubar and role=menu for the construct plus embedded links with no roles. I’m unable to locate a working example that shows this in action though both in IE11 and FF. Is this present on the page? I can’t tell if the required child roles are being added dynamically.
 
The containers with role=menubar or role=menu require focusable children with role=menuitem, or role=menuitemcheckbox, or role=menuitemradio. All ARIA Menu constructs require owned children with these roles.
E.G
and
 
To visually see these roles in action, try using Visual ARIA at
                                http://whatsock.com/training/matrices/visual-aria.htm
 
When the bookmarklet is active and you are using the keyboard, any elements that receive focus that don’t include these roles will be shown in red font.
 
The following Menubar example shows how keyboard functionality is programmed according to spec, which also includes the requisite keyboard information for relevant nodes:
 
                Within the global.css file, the classes are set up so that the required roles plus supporting attributes plus focusability is clearly conveyed as implemented.
 
Though ARIA 1.1 supports the use of aria-orientation to convey the horizontal or vertical layout of role=menubar or role=menu now, there is little to no support for conveying this to screen reader users at present, so the above example includes logic to accomplish this accessibly in the meantime.
 
All the best,
Bryan
 
 
Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
415.624.2709 (o)
 
From: Tanaka, Satoko [[hidden email]] 
Sent: Tuesday, July 19, 2016 7:29 PM
To: WAI IG <[hidden email]>
Subject: Question: Key Operation of Dropdown menu
 
Hi,
 
I would like to ask a question about implementation of dropdown menu created with WAI-ARIA.
 
In this example, there are three types of dropdown menus at the top left corner. The labels are “Section 1”, “Section 2”, and “Section 3”. A breadcrumbs menu is placed just below of the dropdown menu.
When tabbing this example page, the focus is on the menu of “Section 1” first, and next, it moves to “Home” in the breadcrumbs rather than to “Section 2” which is next to “Section 1”.
To move to “Section 2” from “Section 1”, the right arrow key must be used, which means users can operate the dropdown menu with keyboard as long as following a specific key operation.
 
I’m wondering if this example is surely sufficient to WCAG 2.0. I think it might have to provide an instruction of how to operate the dropdown beforehand.
 
My question is:
Is this key operation sufficient to WCAG 2.0? (the point is this implementation does not depend on tab key operation)
In this case, is it necessary to describe how to operate the dropdown menu with keyboard in order to meet SC of WCAG 2.0?
 
I would highly appreciate, if someone kindly would give some good advice to me. Thanks in advance.
 
 
Many thanks and kind regards,
Satoko
 


-- 
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749

“I drink tea and I know things.” 
Falsely attributed to Christophe Lannister.



-- 
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749

“I drink tea and I know things.” 
Falsely attributed to Christophe Lannister.