Re: FW: [ITACCESS] New version of W3C ARIA Authoring Practices available

Hi Jon, all,

Thank you for bringing this up. Because this is a recurring issue/request we discussed this during TPAC day 2. The minutes for this discussion can be found here: https://www.w3.org/2019/09/16-aria-minutes.html#item03

—Zoë Bijl


On Fri, 13 Sep 2019, at 00:34, Gunderson, Jon R wrote:
> The following is another comment on the current utility of the ARIA Authoring practices.

> 

> It appears we need additional information in the patterns and/or the examples to indicate the level of confidence in using the pattern or the example code in real world designs, especially when we have knowledge of the issues with current patterns and examples, otherwise we should maybe change the name of the document to “ARIA Implementation Testing Resources” and not use the word “authoring” in the title.

> 

> Probably the biggest examples in the practices are combobox, spinbutton and slider.

> 

> Jon

> 

> 

> *From:* The EDUCAUSE IT Accessibility Community Group Listserv <ITACCESS@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Kate Deibel
> *Sent:* Tuesday, September 10, 2019 10:09 AM
> *To:* ITACCESS@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [ITACCESS] New version of W3C ARIA Authoring Practices available

> 

> That’s all well and good but there is still the challenge of providing backwards compatibility because not everyone keeps their tech updated to the latest. I have several users who are still super hesitant about Firefox after the Quantum fiasco in 2017. Some are using older computers and new versions expect more memory than they have. Or the cost of upgrading. Or the difficulty in upgrading. These digital divide issues exist and need to be considered when we offer accessible code. Terry’s point (c) assumes that upgrades automatically proliferate to all users.

> 

> A design pattern can include polyfills or fallbacks based on version differences in browsers or assistive tech, especially if we’re talking about a recent change in the specification. And to be clear, I’m not implying we need to extend backwards compatibility out super far like to IE6, Firefox 40, etc. There has to be a limit to backwards compatibility, but even in the past year, I experienced an issue with the gold standard modal pattern because the versions of JAWS, NVDA, and Firefox were not quite yet there due to powers beyond my control (i.e. IT update policies and vendor progress). Given that older code tends to hang around online, we’d also hope that browsers and assistive technologies would still support recommended best practices code from the past. To me, that is universal design.

> 

> So again, my problem is not with a gold standard design patterns. My question/concern is about who we should be pointing to those patterns. Vendors who make browsers and assistive technologies should of course be meeting these standards. As for web developers… I think we need something different. Web developers put forth code into the real world to serve the accessibility needs of many with different technologies of differing quality. Not all developers are accessibility experts, and many just want to plug in code to meet requirements. The ideal design pattern will help some, but there are many who will be left out due to reasons and factors deserving respect.

> 

> *Katherine (Kate) Deibel **| PhD*
> Inclusion & Accessibility Librarian
>  Syracuse University Libraries 

> *T* 315.443.7178
> kndeibel@syr.edu

> 222 Waverly Ave., Syracuse, NY 13244

> Syracuse University

> 

> *From:* The EDUCAUSE IT Accessibility Community Group Listserv <ITACCESS@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Terrill Thompson
> *Sent:* Monday, September 9, 2019 3:17 PM
> *To:* ITACCESS@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [ITACCESS] New version of W3C ARIA Authoring Practices available

> 

> Great question, Kate, and one that comes up a lot.

> 

> My belief is that it's critical for us to have standard, agreed-upon design patterns for common user interfaces, so users can expect those common user interfaces to work the same across all websites. In order for that to work, we need:

> 

> a) Standard, agreed-upon design patterns (the W3C ARIA Authoring Practices serves that role)

> b) Developers to follow the design patterns

> c) Browsers / assistive technologies to support the design patterns

> 

> If there are failures with c), the best course of action is to file a bug with either the AT or browser (or report the issue to others in the community so they can figure out where fault lies and take appropriate action).

> 

> Failures within c) though is not a good argument for failures within b). That old cliche is true here: "Two wrongs don't make a right". Developers should continue to develop according to the design patterns, and should trust that any failures in c) will ultimately be fixed. 

> 

> Reporting issues to Jon is good, since he's active in the W3C trenches. But you can also report and discuss any issues on GitHub:

> https://github.com/w3c/aria-practices/issues

> 

> Regards,

> Terrill

> 


> 
> ---
>  Terrill Thompson
>  Manager, IT Accessibility Team 
>  UW-IT Accessible Technology Services
>  University of Washington
> tft@uw.edu

> 

> 

> On Mon, Sep 9, 2019 at 11:53 AM Gunderson, Jon R <jongund@illinois.edu> wrote:

>> Katherine,

>> 

>> There are some design patterns with the ARIA Practices that may have some implementation issues, like the combobox for example, but the dialog box design pattern should be well supported.

>> 

>> The practices will not guarantee support on Internet Explorer, since accessibility work on ARIA ended on that browser long ago and will not improve.

>> 

>> Can you provide me with design patterns or coding practices you found problems with and the browser/AT combination you have concerns with.

>> 

>> The authoring practices are designed to support authors, so if you do not feel they are providing guidance, the group would like to know what sections you are having problems with.

>> 

>> Jon

>> 

>> 


>> *From:* The EDUCAUSE IT Accessibility Community Group Listserv <ITACCESS@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Kate Deibel
>> *Sent:* Monday, September 9, 2019 1:45 PM
>> *To:* ITACCESS@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [ITACCESS] New version of W3C ARIA Authoring Practices available

>> 

>> Sorry, I realize now your name is Jon and not Joe. I blame seasonal allergies.

>> 

>> *Katherine (Kate) Deibel **| PhD*
>> Inclusion & Accessibility Librarian
>>  Syracuse University Libraries

>> *T* 315.443.7178
>> kndeibel@syr.edu

>> 222 Waverly Ave., Syracuse, NY 13244

>> Syracuse University

>> 


>> *From:* The EDUCAUSE IT Accessibility Community Group Listserv <ITACCESS@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Kate Deibel
>> *Sent:* Monday, September 9, 2019 11:56 AM
>> *To:* ITACCESS@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [ITACCESS] New version of W3C ARIA Authoring Practices available

>> 

>> Joe,

>> 

>> Asking for some clarification, but my understanding of the W3C ARIA Authoring practices (since 1.1 at least) was more to set a gold standard of how browsers and assistive technologies should behave, right? I’ve been increasingly hesitant to point web developers to it as a source of code given that actual real world support may not exist for the community they are serving. For example, a few months ago, I was testing the modal code and my browser/screen reader combo at the time (Firefox/NVDA) did not have proper support for aria-modal. This led to me being able to access parts of the page outside of the modal when it was open. Given that many web developers have to work in a situation of supporting older browsers (and assumingly assistive technologies too), I’ve stopped promoting the ARIA Authoring Practices as a page to go to because there might need to be fallbacks in the code such as polyfills if you want to support your user community.

>> 

>> Your thoughts and comments?

>> 

>> Cheers,

>> 

>> *Katherine (Kate) Deibel **| PhD*
>> Inclusion & Accessibility Librarian
>>  Syracuse University Libraries

>> *T* 315.443.7178
>> kndeibel@syr.edu

>> 222 Waverly Ave., Syracuse, NY 13244

>> Syracuse University

>> 


>> *From:* The EDUCAUSE IT Accessibility Community Group Listserv <ITACCESS@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Gunderson, Jon R
>> *Sent:* Thursday, September 5, 2019 3:25 PM
>> *To:* ITACCESS@LISTSERV.EDUCAUSE.EDU
>> *Subject:* [ITACCESS] New version of W3C ARIA Authoring Practices available

>> 

>> A new version of the W3C ARIA Authoring Practices was published last month.

>> https://www.w3.org/TR/wai-aria-practices-1.1/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_wai-2Daria-2Dpractices-2D1.1_&d=DwMFAg&c=Y6HT0gyZH_Z4ZSRJdNYJeQ&r=J9v0mCONcq6yW8Wqn227MJFNuytPEyFm-SWYS8R5nwA&m=VN-xfNA7cSdQMwATWGhgcn37PxMcncN4zF08beCWlXw&s=9EPr81pW1cAaL-RkStEGTnr3Y1CSTDa4EJN18RPp38U&e=>

>> 

>> Changes from last publication:

>> https://www.w3.org/TR/wai-aria-practices-1.1/#change_log <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_wai-2Daria-2Dpractices-2D1.1_-23change-5Flog&d=DwMFAg&c=Y6HT0gyZH_Z4ZSRJdNYJeQ&r=J9v0mCONcq6yW8Wqn227MJFNuytPEyFm-SWYS8R5nwA&m=VN-xfNA7cSdQMwATWGhgcn37PxMcncN4zF08beCWlXw&s=MRRQr8n70vcG5NQ5dKh6KZNmXCRN2BmzKoBK0kK0lGY&e=>

>> 

>> This is a useful resource for web developers and designers to understand how to use ARIA markup to create WCAG 2.1 compliant web resources and can also be used by quality assurance testers to developing testing protocols and provide feedback to developers and designers.

>> 

>> Jon

>> 

>> 

>> Jon Gunderson, Ph.D., CPWA

>> Coordinator of Accessible IT Group

>> University of Illinois at Urbana/Champaign

>> 1207 S. Oak Street

>> Champaign, IL 61820

>> 

>> www: https://go.illinois.edu/jongund <https://urldefense.proofpoint.com/v2/url?u=https-3A__go.illinois.edu_jongund&d=DwMFAg&c=Y6HT0gyZH_Z4ZSRJdNYJeQ&r=J9v0mCONcq6yW8Wqn227MJFNuytPEyFm-SWYS8R5nwA&m=VN-xfNA7cSdQMwATWGhgcn37PxMcncN4zF08beCWlXw&s=RtDD3ZHitP4c0GSXfRoIIlLKBZkXHKCQNv7mn9WENqs&e=>

>> 


>> **********
>>  Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community


>> **********
>>  Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community


>> **********
>>  Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community


>> **********
>>  Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community


> **********
>  Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community


> **********
>  Replies to EDUCAUSE Community Group emails are sent to the entire community list. If you want to reply only to the person who sent the message, copy and paste their email address and forward the email reply. Additional participation and subscription information can be found at https://www.educause.edu/community