WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Mega Menu and Safari

for

From: Brooks newton
Date: Apr 1, 2016 7:12PM


Why are all of us developers who are dedicated to digital content accessibility left with having to submit bugs to operating system, browser and assistive technology manufacturers when they render our carefully crafted, and increasingly regulated accessible code useless through new software releases? Why not require these software manufacturers comply with the standards we have so willingly accepted as business as usual?

Here's a case in point. It is incredibly difficult to get large enterprise sites to make wholesale changes to the content design and to the supporting code base for the purpose of enhancing accessibility. I know, because I have been in this position. For massive web sites it takes a lot of time and money, for example, to revamp a single global page component, such as a navigation menu. We are talking millions of dollars and months of work by delivery teams spread across multiple continents to implement this type of accessibility enhancement. If we are lucky enough to get the accessible change we ask for as advocates of accessibility, it is very deflating to have the accessible benefit undone by no fault of our own, but rather as a result of an unregulated operating system, browser, and/or assistive technology software release.

For the most part, the unregulated, voluntary approach to suggesting accessible site/app code improvement hasn't worked for site visitors with disabilities who contact site owners for help in making content accessible. If it had worked, we would have no need for the ADA and Section 508 refresh efforts in the U.S. By the way, why are software and device manufacturers excluded from an obligation to comply with WCAG 2.0 as it is incorporated in these evolving standards?

As it now stands, the burden of ensuring digital accessibility lies squarely on the shoulders of content owners and the production staff they hire to design, develop and maintain web sites, mobile apps, etc. One exception to this lopsided norm is the CVAA in the United States, which requires device and software manufacturers to pass through accessible accommodations that are put into the digital video content by the content owners. Other evolving accessibility standards should follow suit with the CVAA in this regard.

Why don't we demand from our regulators and legislators that software manufacturers do their requisite parts to make the digital content ecosphere accessible by design, rather than having to endure the whack-a-mole approach to developing and disseminating the latest accessible hacks as the primary path to accessing digital content in the future?

Why are we forced to be satisfied with the dribble of brilliant, but likely tentative one off fixes from hard working sources scattered across the web (thanks Bryan, Terrill, Steve, Gez, and many others) to make our advanced interfaces accessible? How about engaging these minds and many other capable folks in planning a set of carefully selected design patterns that represent the state of the art digital content technology? The creation of this basic design pattern library with accompanying real world code examples could be undertaken in conjunction with software manufacturers, who will be bound by law to pass through and/or parse approved code solutions in an accessible fashion. The pattern library would form a common basis for establishing informative standards that would facilitate widespread adoption of accessibility in the digital content industry.

There's got to be a better way of building momentum, strengthening trust and sharing the workload as we fight the good fight.

Brooks Newton
Independent Digital Accessibility Consultant





Sent from my iPad



Sent from my iPad
> On Mar 31, 2016, at 5:15 PM, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>
> Not premature, the more bugs that are filed with different steps to reproduce, the better.
>
> This also effects iOS, where VO isn't tracking focus movement properly.
>
> E.G
> http://whatsock.com/tsg/Coding%20Arena/Modals/Modal%20(Internal%20Content)/demo.htm
>
> It appears that when element.focus() is used to set focus to an element, VO in iOS will do so when the element is onscreen, however when setting focus to an offscreen element such as in the modal above in order to set focus to the beginning of the modal content, VO will not be moved.
>
> As a result, when swiping from left to right or right to left using one finger, focus appears to be stuck on the Login button even though this is already hidden using aria-hidden="true" at this point.
>
> This is an iOS bug, because it is still possible to read such offscreen content such as hidden headings and the like when swiping from left to right in this manner on iOS, so there should be no reason why focus can't be set to this location as well. This is often how focus is handled for dynamic content regions that are opened when there is no otherwise logical place to set focus other than by using an offscreen element at the beginning of the content region.
>
> Another issue is that, at least on iOS using VO, dynamic elements or content that is dynamically updated within a heading is not being recognized by VoiceOver. Such as when a heading is also a live region using aria-live="polite", and when an interactive role state changes, such as when toggling a button within a heading that includes aria-pressed="true" or aria-pressed="false", where the state change is not being recognized.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Robert Fentress
> Sent: Thursday, March 31, 2016 12:12 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Accessible Mega Menu and Safari
>
> Thanks, Bryan. I thought I had tested it before and it had worked. Glad I'm not going crazy--or at least that this is not sufficient proof to have me committed! ;-) Still, bad news for people expecting to interact successfully with complex custom widgets using only the keyboard.
>
> Anybody filed a bug report with Apple? Or is that premature?
>
>> On Thu, Mar 31, 2016 at 1:44 PM, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>>
>> We've been noticing lately that there are now some fairly critical
>> issues in VO + Safari that are impacting focus handling when combined
>> with dynamic content triggering, which used to work reliably in the past.
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>> Behalf Of Jonathan Avila
>> Sent: Thursday, March 31, 2016 10:04 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] Accessible Mega Menu and Safari
>>
>> IMO It's either in VoiceOver or Safari an elements is focused, blurred
>> and then focused again. This chain doesn't appear to happen in Chrome
>> with VoiceOver or on Windows.
>>
>> Jonathan
>>
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> <EMAIL REMOVED>
>> 703.637.8957 (Office)
>> Visit us online: Website | Twitter | Facebook | Linkedin | Blog Check
>> out our Digital Accessibility Webinars!
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>> Behalf Of Robert Fentress
>> Sent: Thursday, March 31, 2016 12:59 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Accessible Mega Menu and Safari
>>
>> Thanks for checking this, Jonathan. So, you are saying it is a Safari
>> bug, not a bug with the mega menu itself?
>>
>> Best,
>> Rob
>>
>> On Thu, Mar 31, 2016 at 9:50 AM, Jonathan Avila <
>> <EMAIL REMOVED> >
>> wrote:
>>
>>> Regarding support with VoiceOver on the Mac, I ran a test with
>>> chrome and VoiceOver and the mega menu did not auto collapse. I
>>> then went to my event testing page
>>> (https://labs.ssbbartgroup.com/index.php/Event_Watcher) and used the
>>> control+option+left arrow keys to move around several different
>>> control+option+types
>>> of controls to see what might be causing the issue. I find that
>>> with VoiceOver in Safari an extra blur event is being fired between
>>> focus events
>>> -- that is when some elements are focused with control+option+left
>>> arrow a focus event followed by a blur event followed by a focus
>>> event all on the same element are fired. This is not the case when
>>> tab is pressed. This seems like a bug.
>>>
>>> Jonathan
>>>
>>> Jonathan Avila
>>> Chief Accessibility Officer
>>> SSB BART Group
>>> <EMAIL REMOVED>
>>> 703.637.8957 (Office)
>>> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
>>> Check out our Digital Accessibility Webinars!
>>>
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>>> Behalf Of Robert Fentress
>>> Sent: Wednesday, March 30, 2016 12:37 PM
>>> To: WebAIM Discussion List
>>> Subject: Re: [WebAIM] Accessible Mega Menu and Safari
>>>
>>> Thanks, Paul.
>>>
>>> The problem with using down arrow with QuickNav off or Tab, in this
>>> instance, is that this only moves between links and skips over
>>> non-focusable elements. The purpose of the mega menu pattern, as
>>> used here, is that you want to make other structured content besides
>>> the menu links available, for instance, headings or textual cues.
>>> That content is skipped using these navigation methods, at least,
>>> apparently, with how I have VoiceOver set up.
>>>
>>> As to the ARIA Authoring Practices, while those are valuable, if
>>> your are doing something application-like, if you are using menus in
>>> the way commonly found on web pages, you would likely violate many
>>> users expectations by following the spec. As others have noted, web
>>> applications--not to mention regular web sites that make sporadic
>>> use of custom controls--are not the same as desktop applications.
>>> That being said, mapping to system APIs does provide value. It is a
>>> difficult nut to crack.
>>>
>>> On Wed, Mar 30, 2016 at 11:47 AM, Paul J. Adam < <EMAIL REMOVED> >
>>> wrote:
>>>> Looks like it only works if you press the down arrow key with
>>>> VoiceOver
>>> quick navigation turned off. Or Tab into the menu.
>>>>
>>>> It would be smart for JavaScript widgets that have various
>>>> keyboard
>>> navigation methods to display a visible tooltip or show some
>>> instructions on how to actually operate the menu. Those instructions
>>> being accessible to screen reader users also.
>>>>
>>>> This menu works as you're expecting with VO+Right Arrow key.
>>>> http://www.washington.edu/accesscomputing/AU/after.html
>>>> <http://www.washington.edu/accesscomputing/AU/after.html>;
>>>>
>>>> Here's the ARIA Authoring Practices with keyboard interaction
>>>> instructions, https://www.w3.org/TR/wai-aria-practices/#menu
>>>> <https://www.w3.org/TR/wai-aria-practices/#menu>
>>>>
>>>> Paul J. Adam
>>>> Accessibility Evangelist
>>>> www.deque.com
>>>>
>>>>> On Mar 30, 2016, at 10:18 AM, Robert Fentress < <EMAIL REMOVED> > wrote:
>>>>>
>>>>> Hi, all.
>>>>>
>>>>> I've just noticed a problem with the way Adobe's Accessible Mega
>>>>> Menu (
>>>>> https://adobe-accessibility.github.io/Accessible-Mega-Menu/)
>>>>> works with Safari and VoiceOver. Basically, when you activate a
>>>>> menu with
>>>>> Control+Option+Space the menu appears, but when you then press
>>>>> Control+Option+Right Arrow to have VO voice the text in the menu,
>>>>> Control+Option+the menu
>>>>> collapses. It only stays open if you tab into the revealed contents.
>>>>> This, of course, kinda defeats one of the points of this pattern,
>>>>> in that it means that you really only have access to the menu
>>>>> options, not the other structured content. In that case, you
>>>>> might as well just make it a more standard menu.
>>>>>
>>>>> I could have sworn I'd tested this before and it had worked. Do
>>>>> you know if anything has changed in recent updates to Safari or
>>>>> VoiceOver that would have affected this, or did I just miss it
>> previously?
>>>>>
>>>>> On a related note, if you are stuck with this basic turducken
>>>>> mega menu pattern, is there an implementation that works better
>>>>> than Adobe's? If I could convince the people I'm making
>>>>> recommendations to to deviate slightly from the strict mega menu
>>>>> pattern, would a mega modal be better and, if so, do you know of
>>>>> some particularly good
>>> implementations?
>>>>>
>>>>> Best,
>>>>> Rob
>>>>>
>>>>> --
>>>>> Robert Fentress
>>>>> Senior Accessibility Solutions Designer
>>>>> 540.231.1255
>>>>>
>>>>> Technology-enhanced Learning & Online Strategies Assistive
>>>>> Technologies
>>>>> 1180 Torgersen Hall
>>>>> 620 Drillfield Drive (0434)
>>>>> Blacksburg, Virginia 24061
>>>>> >>>>> >>>>> archives at http://webaim.org/discussion/archives
>>>>> >>>>
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>>
>>>
>>>
>>> --
>>> Robert Fentress
>>> Senior Accessibility Solutions Designer
>>> 540.231.1255
>>>
>>> Technology-enhanced Learning & Online Strategies Assistive
>>> Technologies
>>> 1180 Torgersen Hall
>>> 620 Drillfield Drive (0434)
>>> Blacksburg, Virginia 24061
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>
>>
>>
>> --
>> Robert Fentress
>> Senior Accessibility Solutions Designer
>> 540.231.1255
>>
>> Technology-enhanced Learning & Online Strategies Assistive
>> Technologies
>> 1180 Torgersen Hall
>> 620 Drillfield Drive (0434)
>> Blacksburg, Virginia 24061
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>> >> >> archives at http://webaim.org/discussion/archives
>> >
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > >
>