jQuery UI 1.10.4 is out with bug fixes and accessibility improvements

[Jennifer Sutton]

Free-ARIA:

More news from the jQuery space.

@dylanbarrell retweeted @jqueryui:

jQuery UI 1.10.4 is out with bug fixes and accessibility
improvements! http://t.co/kUcamzo1Bo

Friday, January 17, 2014 at 3:45:50 PM
http://twitter.com/jqueryui/status/424244586177773568

[Bryan Garaventa]

Congratulations :)

Have these changes been pushed to the live site yet for testing?

----- Original Message -----
From: "Jennifer Sutton" <jsut...@gmail.com>
To: "free-aria-googlegroups.com" <free...@googlegroups.com>
Sent: Saturday, January 18, 2014 12:10 PM
Subject: [free-aria] jQuery UI 1.10.4 is out with bug fixes and
accessibility improvements


> Free-ARIA:
>
> More news from the jQuery space.
>
> @dylanbarrell retweeted @jqueryui:
>
> jQuery UI 1.10.4 is out with bug fixes and accessibility improvements!
> http://t.co/kUcamzo1Bo
>
> Friday, January 17, 2014 at 3:45:50 PM
> http://twitter.com/jqueryui/status/424244586177773568
>

> --
> You received this message because you are subscribed to the Google Groups
> "Free ARIA Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to free-aria+...@googlegroups.com.
> To post to this group, send email to free...@googlegroups.com.
> Visit this group at http://groups.google.com/group/free-aria.
> For more options, visit https://groups.google.com/groups/opt_out.

[Scott González]

Yes, the changes are on jqueryui.com. The accessibility related issues that were fixed are:

• Accordions were previously setting aria-expanded on the panel instead of the tab. I know you think we should stop using tablist for accordion. I'm open to having this discussion with a larger group, but I haven't gotten around to it yet. Fixing this in the meantime seemed important.
• Button would not lose their focus styling when becoming disabled in certain browsers on Windows.
• Dialogs opened from a menu don't receive focus.
• Focused anchors inside headers were receiving the wrong styling when using our CSS Framework.

If you'd like to test the standalone demos, they're available on http://view.jqueryui.com/1.10.4/demos/. The view server should only be used for testing purposes. All demos for the current version are also hosted on http://jqueryui.com for presentation and quick reference.

We have more accessibility improvements in master (planned for the 1.11.0 release) as well. We hope to have this out soonish.

On Sun, Jan 19, 2014 at 5:07 AM, Bryan Garaventa <bryan.g...@whatsock.com> wrote:

Congratulations :)

Have these changes been pushed to the live site yet for testing?

----- Original Message ----- From: "Jennifer Sutton" <jsut...@gmail.com>
To: "free-aria-googlegroups.com" <free...@googlegroups.com>
Sent: Saturday, January 18, 2014 12:10 PM
Subject: [free-aria] jQuery UI 1.10.4 is out with bug fixes and accessibility improvements

Free-ARIA:

More news from the jQuery space.

@dylanbarrell retweeted @jqueryui:

jQuery UI 1.10.4 is out with bug fixes and accessibility improvements! http://t.co/kUcamzo1Bo

Friday, January 17, 2014 at 3:45:50 PM
http://twitter.com/jqueryui/status/424244586177773568

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+unsubscribe@googlegroups.com.

To post to this group, send email to free...@googlegroups.com.
Visit this group at http://groups.google.com/group/free-aria.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+unsubscribe@googlegroups.com.

[Bryan Garaventa]

Thanks, I understand.

 

Do modals still use role=dialog on the container?

 

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+...@googlegroups.com.

[Scott González]

On Sun, Jan 19, 2014 at 1:46 PM, Bryan Garaventa <bryan.g...@whatsock.com> wrote:

Thanks, I understand.

 

Do modals still use role=dialog on the container?

Yes, and we don't use aria-hidden for page content.

[Bryan Garaventa]

Is there any verbiage in the download that describes all of the other requirements when this is applied for developers, like the use of aria-label to set a dialog label, explicit field association for all form fields using the label element or aria-label or aria-labelledby or aria-describedby, the necessity of using tabindex=0 with role=document for all static content regions, etc?

 

My concern is that, the vast majority of developers using this widget will not know or understand how to implement any of these things reliably, which is confirmed by my testing over the last couple of years where I've seen this to be true.

 

Also, it's hard to explain why the addition of role=dialog is supposed to increase accessibility for screen readers in any way, so you get many negatives and no definitive positives by doing it.

 

----- Original Message -----

From: Scott González

To: free...@googlegroups.com

Sent: Sunday, January 19, 2014 11:07 AM

Subject: Re: [free-aria] jQuery UI 1.10.4 is out with bug fixes and accessibility improvements

--

[Scott González]

On Sun, Jan 19, 2014 at 3:54 PM, Bryan Garaventa <bryan.g...@whatsock.com> wrote:

Is there any verbiage in the download that describes all of the other requirements when this is applied for developers, like the use of aria-label to set a dialog label,

This happens automatically.

 

explicit field association for all form fields using the label element

If they can't get this right, there's really no hope for them to build an accessible app.

 

or aria-label or aria-labelledby or aria-describedby,

We don't document general programming practices.

 

the necessity of using tabindex=0 with role=document for all static content regions, etc?

How is this related to the dialog? Placing aria-hidden on the entirety of the page is equivalent to a modal (which is all ARIA really supports, right?) So the user isn't going to be navigating to other content regions while a modal dialog is open anyway.

My concern is that, the vast majority of developers using this widget will not know or understand how to implement any of these things reliably, which is confirmed by my testing over the last couple of years where I've seen this to be true.

We do what we can to ensure our widgets are accessible out of the box and that it's hard for users to break our accessibility. If we can't ensure that, we won't release the widget. This is why we don't have a menubar widget.

 

Also, it's hard to explain why the addition of role=dialog is supposed to increase accessibility for screen readers in any way, so you get many negatives and no definitive positives by doing it.

Can you provide concrete examples where not using the role is better than using the role?

[Bryan Garaventa]

Regarding labels and descriptions, "If they can't get this right, there's really no hope for them to build an accessible app."

 

That's true, however labeling with ARIA can encompass supplementary descriptive text as well as explicit label text, and if role=dialog is applied and one of these, such as form field constraint data for example, is missing, it renders the critical data entirely inaccessible for NVDA users, since only active elements can receive keyboard focus within a container including role=dialog, because Browse Mode is not allowed.

 

"We don't document general programming practices."

 

I understand that, but if you are adding role=dialog automatically, you are forcing developers to either remove it manually or for them to be susceptible to all of the associated pitfalls without general guidance on how to ensure accessibility as a result.

 

Regarding the use of tabindex=0 and role=document, "How is this related to the dialog? Placing aria-hidden on the entirety of the page is equivalent to a modal (which is all ARIA really supports, right?) So the user isn't going to be navigating to other content regions while a modal dialog is open anyway."

 

Since you are providing an empty container that developers can populate with any type of markup, it's necessary to ensure that all types can be accessed by screen readers. I understand that the assumption is that only active elements will be included within a modal, but I've found that this is rare, since descriptive static text is often included to identify the purpose, supplementary details such as license data or help text, and various other types of content. Also, structured data can also be added, such as data table markup in some cases. Since it's literally impossible to enter Browse Mode using NVDA within a container including role=dialog, all of this static content will be 100% inaccessible unless it is marked up using a method such as role=document and tabindex=0 within the dialog container.

 

From the W3C Roles Model: http://www.w3.org/TR/wai-aria/roles#document
"When the user navigates an element assigned the role of document, assistive technologies that typically intercept standard keyboard events SHOULD switch to document browsing mode, as opposed to passing keyboard events through to the web application. The document role informs user agents of the need to augment browser keyboard support in order to allow users to visit and read any content within the document region. In contrast, additional commands are not necessary for screen reader users to read text within a region with the application role, where if coded in an accessible manner, all text will be semantically associated with focusable elements. An important trait of documents is that they have text which is not associated with widgets or groups thereof."

 

"Can you provide concrete examples where not using the role is better than using the role?"

 

Yes, of course.

 

I've built three identical dialog content containers that include mixed content. All of the elements within the container are ones I've seen implemented publically in the past three years. I've not included any visual styling since it's not applicable for the demo.

 

The first includes no role=dialog, and is fully accessible in IE, FF, Chrome, and Safari using JAWS, NVDA, and VoiceOver.
http://whatsock.com/test/without-role-dialog.htm
A screen reader user can arrow through the content in the Virtual Buffer or tab between the active elements, and all of the textual information is accessible.

 

This second page includes role=dialog on the same container, as well as all of the requisite ARIA attributes including tabindex=0 and role=document to ensure accessibility for NVDA users.
http://whatsock.com/test/with-role-dialog.htm
Even so, in FF using NVDA, it's impossible to read the explicit label for the File Upload field because the edit field is automatically taken out of the tab order by the browser.

 

Now, this third page includes only role=dialog and aria-label and includes no other ARIA attributes to ensure accessibility for the embedded content. If a developer is unaware of what role=dialog actually does, and there is no general ARIA guidance to indicate what is required, then this is the most likely way that this will be implemented.
http://whatsock.com/test/with-only-role-dialog.htm
You can see that all of the static content and supplementary form field text is totally inaccessible for NVDA users in IE, FF, and Chrome.

 

So basically, all of the markup changes done in the second dialog are to fix major accessibility issues caused by adding role=dialog on the first dialog that is already fully accessible without role=dialog.

 

As a side note, all of the same issues occur for role=alertdialog and role=application as well.

 

Also, if you want to hide the background content for VoiceOver users on iOS touch screen devices, role=dialog won't do anything. Only the aria-hidden method works for this.

 

----- Original Message -----

From: Scott González

To: free...@googlegroups.com

Sent: Sunday, January 19, 2014 1:04 PM

Subject: Re: [free-aria] jQuery UI 1.10.4 is out with bug fixes and accessibility improvements

--