E-mail List Archives
Thread: Accessible Mega Menu and Safari
Number of posts in this thread: 22 (In chronological order)
From: Robert Fentress
Date: Wed, Mar 30 2016 9:18AM
Subject: Accessible Mega Menu and Safari
No previous message | Next message →
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, 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
From: Paul J. Adam
Date: Wed, Mar 30 2016 9:47AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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 ADDRESS 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, 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
> > > >
From: Moore,Michael (Accessibility) (HHSC)
Date: Wed, Mar 30 2016 10:02AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
I thought that the original post concerned different behavior between Safari/VoiceOver vs. windows based screen readers. So the problem becomes how do you provide instructions when what you need to do is different based upon the OS/AT/Browser combination. I could see the instructions becoming very unwieldy very fast. Not to mention that most organizations do not even possess the expertise to manage that level of detail in the instructions. For example we are strictly a Microsoft house and when we are lucky our developers understand how to use JAWS with IE. Macs are confined to our graphic designers who think that AT stands for Artistic Trauma and that VoiceOver is something performed by David Attenborough.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
From: Robert Fentress
Date: Wed, Mar 30 2016 10:36AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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, 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
>> >> >> >> >
> > > > --
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
From: _mallory
Date: Wed, Mar 30 2016 11:08AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
On Wed, Mar 30, 2016 at 12:36:55PM -0400, Robert Fentress wrote:
> 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.
I avoided the whole menu thing from aria practices when making my
megas because I'm convinced menu/menuitem roles should only be used
for application menus-- where instead of links, you have controls.
Clicking them should Do Stuff (open a file, save, edit, whatever).
However what I used wasn't 100% in my book either: tab keys (on
desktop) went from top-level item to top-level item. Enter selected
that link to take you to that category page. When an item was focussed,
the submenu appears. Arrows could cycle around there (and anything else
in there could be normally navigated at least by desktop SRs, I didn't
and still really don't have any mobiles to test anything on). The submenu
remained onscreen so long as we didn't either move focus to the next/prev
main item or out of the menu entirely.
This may be considered breaking the rule that focus doesn't make changes
to a page, however these pages were already doing so with hover and
that was completely what the users expected (nobody expected a submenu
to appear by clicking-- they expected to navigate elsewhere with
clicking). I also could have maybe improved with something like active
descendent or has popup or whatever, but at the time I was building
these, haspopup was in the middle of a spec change and I had left it.
It's quite likely these didn't work well on VO anyway.
cheers,
_mallory
>
> On Wed, Mar 30, 2016 at 11:47 AM, Paul J. Adam < = EMAIL ADDRESS 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 ADDRESS 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, 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
> >> > >> > >> > >> > >
> > > > > > > > >
>
>
> --
> 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
> > > >
From: Jonathan Avila
Date: Thu, Mar 31 2016 7:50AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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 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 ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!
From: Robert Fentress
Date: Thu, Mar 31 2016 10:59AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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 ADDRESS 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
> 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 ADDRESS REMOVED =
> 703.637.8957 (Office)
> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> Check out our Digital Accessibility Webinars!
>
>
>
From: Jonathan Avila
Date: Thu, Mar 31 2016 11:03AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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 ADDRESS REMOVED =
703.637.8957 (Office)
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!
From: Bryan Garaventa
Date: Thu, Mar 31 2016 11:44AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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.
From: Robert Fentress
Date: Thu, Mar 31 2016 1:12PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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 ADDRESS 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.
>
>
From: Bryan Garaventa
Date: Thu, Mar 31 2016 4:15PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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.
From: Brooks newton
Date: Fri, Apr 01 2016 7:12PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
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 ADDRESS 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.
>
>
From: Bryan Garaventa
Date: Mon, Apr 04 2016 2:52PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
I understand the frustration, having been dealing with the same situation for many years.
The value however for focusing on a single spec compliant approach for authoring, is that the specification is meant to be equally followed across all browsers as a common goal. So when spec compliant code is implemented, it doesn't have to be constantly updated by developers all the time to achieve a specific result.
As you mentioned, this is a moving target, and some browsers do this better than others, but as time goes on and more and more browsers refer to the same spec for this functionality, then your code implementation will automatically become more accessible in the future in these other browsers as well, without requiring constant updating to achieve on your end.
If we do it the other way though, where developers are responsible for reinventing the wheel every time to get a specific behavior or result in one AT/browser combination, then have to do this differently for every variation, nothing will ever work right in the future, because it will be impossible to achieve interoperability without requiring a complete rewrite of all such frameworks to do it again from scratch.
From: Bryan Garaventa
Date: Mon, Apr 04 2016 2:57PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
Sorry, hit send too soon...
This really comes down to education and seeding accessible development practices within the educational process for mainstream development, thus narrowing the margins for error in the future.
Pattern libraries work too, as I've done with the TSG at
https://github.com/accdc/tsg
But the concepts that govern development of such patterns is what developers need to learn and be aware of, otherwise they will never know why these things work accessibly on their own.
From: Moore,Michael (Accessibility) (HHSC)
Date: Mon, Apr 04 2016 3:11PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
The Web Accessibility Initiative (WAI) at the W3C has developed guidelines that if followed would result in better support for accessibility.
The User Agent Accessibility Guidelines (UAAG) define how the browsers and assistive technology are expected to handle content that is developed to meet the Web Content Accessibility Guidelines. I could certainly argue that if a browser fails to provide support for accessibility features built to meet the guidelines that they could be liable under the ADA for not making their software accessible.
The second set of guidelines is the Authoring Tool Accessibility Guidelines. These guidelines establish criteria for ensuring that the tools that we use to create content are both accessible to use for people with disabilities and support the development of accessible content. Again I could see that making the software itself accessible would be covered by the ADA and similar laws in other countries. However the output is another matter since that responsibility rests with the authors. But here is where we can make a difference. If we ask for tools that are ATAG compliant and reward companies that create tools that make it easier to create accessible content by preferring to purchase those tools over the tools that make it hard to create accessible content we can move the market.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
From: Bryan Garaventa
Date: Mon, Apr 04 2016 5:29PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
Absolutely right.
For people to make accessible tools though, they first have to learn and understand how to make accessible software... :)
I think we are saying the same thing.
We need to better educate engineers regarding accessibility, who then build better accessibility related tools and CMS frameworks, which more people can utilize and learn from to create and propagate more accessible software in accordance with reliable standards.
From: Brooks newton
Date: Mon, Apr 04 2016 11:39PM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
Bryan & Mike,
Thank you for your thoughtful replies to my list message. We are definitely on the same sheet, in terms of acknowledging the value of developing specification compliant solutions as a best practice. But if developers are following the specs, and the software that processes the compliant code is not spec friendly, then we as the architects of the user experience will likely fall short of the ultimate goal which is providing actual access to content by end users with disabilities. It takes two to tango, so if the software isn't performing its part, then we are just dancing with ourselves.
I'm not sure that most organizational clients who pay expensive consultation fees and salaries, not to mention those who go a step further and pay the much greater costs associated with implementing theoretically compliant, yet ultimately inaccessible recommendations, want to make expensive principled points that ultimately fail to provide actual full accessibility. Or, maybe some clients are OK with throwing money at the problem without a care as to the efficacy of what they've paid for. Sadly, I believe some organizations believe that spending money on accessibility is enough to throw up a force field of protection from civil rights litigation.
As Jared suggests with his tongue in cheek carousel example, my belief is that we in this business need to say, "no, you can't implement that type of widget if your goal is to provide accessible digital content" a lot more often. Most of the time, my experience has shown me that professional accessibility experts don't want to tell a client no. It often doesn't pay to say no. I personally understand that dilemma. In the instances where "no" is the best answer, it's most often a case of responsible consultants acknowledging a failure of the various software configurations to render an accessible output from specification compliant code.
Using assistive technology, I've browsed a lot of beautifully coded, fully compliant "solutions" that just plain don't output accessible results. I'm sure I'm not the only one on this list who has encountered this phenomenon. Sure, there are instances where the design pattern in question is just simply ahead of the curve, in terms of outpacing the available markup and scripting in our toolboxes, but this is rare in my experience. The sharp folks at the W3C have anticipated the code required to handle most types of content and controls I have run across out there in the wild. Thanks for that, by the way!
In order for the robustness of our spec compliant code to mean anything, I believe that we, our clients and their customers with disabilities must push harder for OS, user agent, and AT engineers to do their own bug checking during development, as well as after release. They need to have more skin in the accessibility game. Frankly, I think what will ultimately be required to move our cause forward by leaps and bounds, as Mike alludes to, are lawsuits that hold the software manufactures accountable for keeping their links strong to support the overall integrity of the chain of accessibility.
Talk with You Later,
Brooks Newton
Independent Digital Accessibility Consultant
> On Apr 4, 2016, at 6:29 PM, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
>
> Absolutely right.
>
> For people to make accessible tools though, they first have to learn and understand how to make accessible software... :)
>
> I think we are saying the same thing.
>
> We need to better educate engineers regarding accessibility, who then build better accessibility related tools and CMS frameworks, which more people can utilize and learn from to create and propagate more accessible software in accordance with reliable standards.
>
>
From: Moore,Michael (Accessibility) (HHSC)
Date: Tue, Apr 05 2016 7:22AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
One thing that we definitely can do is to file bug reports with the companies that build the browsers, assistive technologies, and the content creation tools. We have done this and found that most of the companies are reasonably responsive.
We have received the best responses when we have been able to provide the following.
1. Example code or a link to a publically available resource that demonstrates the problem.
2. Detailed steps for how to recreate the problem.
3. Detailed analysis that demonstrates why the problem exists in their product and not somewhere else in the accessibility stack.
4. Detailed explanation of what behavior we expect.
5. Side by side comparison with competitive products that behave correctly.
6. Contact information to a qualified person who is thoroughly knowledgeable about the problem.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
From: Guy Hickling
Date: Tue, Apr 05 2016 7:36AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
I think Brooks Newton has summarised the current position excellently.
His comment about how we all "must push harder for OS, user agent, and
AT engineers to do their own bug checking" is very true.
Further to that, perhaps the proposed European Accessibility Act will
put a bit more pressure on manufacturers, particularly of computers,
operating systems and smart phones (and their "user interface and
functionality design") which are some of the specific items it covers,
to get it right before they put out new releases. With that
legislation (and subsequent implementation by the individual
countries) accessibility bugs will no longer be merely bugs, but will
become actual infringements against the law.
It won't stop these problems ever happening, of course (a bug is by
definition unintentional). But they often get through due to not doing
enough testing, so the EAA should help raise the stakes and pressure
the software manufacturers to pay more attention to the accessibility
testing of their products.
Regards,
Guy Hickling
From: Brian Lovely
Date: Tue, Apr 05 2016 7:50AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
I am not familiar with the Brooks Newton comment, but as a front end web developer I understand the need for testing at the development levels, but also the challenges the developer faces in this regard.
A dev not only needs the tools (test machines with various OS and browsers installed, some service like BrowserStack or Sauce Labs) but also the time for testing built into the scope and budget for the project. This is typically not the case. Usually there is a paucity of test devices (sorry, BrowserStack, you are still not a complete replacement for physical devices), those that are provided are on their last legs, front end testing is not well understood nor supported.
I've worked at places where the FE leads swore that we would begin using a JS testing framework like Jasmine on the next project only to have to scrap that in the face of time and budget constraints.
…and I have never worked at a place where they had bought a license for JAWS.
Brian Lovely
= EMAIL ADDRESS REMOVED =
> On Apr 5, 2016, at 9:36 AM, Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
>
> I think Brooks Newton has summarised the current position excellently.
> His comment about how we all "must push harder for OS, user agent, and
> AT engineers to do their own bug checking" is very true.
>
> Further to that, perhaps the proposed European Accessibility Act will
> put a bit more pressure on manufacturers, particularly of computers,
> operating systems and smart phones (and their "user interface and
> functionality design") which are some of the specific items it covers,
> to get it right before they put out new releases. With that
> legislation (and subsequent implementation by the individual
> countries) accessibility bugs will no longer be merely bugs, but will
> become actual infringements against the law.
> It won't stop these problems ever happening, of course (a bug is by
> definition unintentional). But they often get through due to not doing
> enough testing, so the EAA should help raise the stakes and pressure
> the software manufacturers to pay more attention to the accessibility
> testing of their products.
>
> Regards,
> Guy Hickling
> > > >
From: Brian Lovely
Date: Tue, Apr 05 2016 8:01AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | Next message →
Brooks, I'm glad I went back and found this post. I commented on a later portion of the thread and now see that I did not fully understand the direction of your comments. That said, I stand by what I said in my post, but your points are well made. I will say that browser companies have come a long way from the bad old days of browser wars and no standards.
It is interesting that OS and device manufactures are somewhat exempt from scrutiny in the area of accessibility. Hats off to Apple for there work on accessible touch devices, and their adding the results of that work (VoiceOver) to their keyboard devices.
Brian Lovely
= EMAIL ADDRESS REMOVED =
> On Apr 1, 2016, at 9:12 PM, Brooks newton < = EMAIL ADDRESS REMOVED = > wrote:
>
> 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 ADDRESS 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.
>>
>>
From: Bryan Garaventa
Date: Tue, Apr 05 2016 10:31AM
Subject: Re: Accessible Mega Menu and Safari
← Previous message | No next message
Thanks, I do understand your points and agree with many of them.
I've been working with clients to build accessible software since 2004, and in totality it does represent millions in time and monetary expense for accomplishing this, and often solutions that were coded that far back have better and more effective equivalents now that can be utilized for better accessibility. This will always be part of the challenge as our technologies evolve and become ever more complex.
It's important to note that the concept of "full accessibility" is literally impossible however, and anybody who requests this or represents that this is possible, is not being realistic. There is no way to provide full accessibility for every technology in combination with every possible disability type in existence. All we can do is raise the bar as high as we can given our current level of advancement to make what we build as accessible to as many people as possible.
We at the W3C are currently working on better general design patterns, but even so, it is impossible to account for all possible combinations and implementations. This is why understanding how these technologies work is so important, because when this level of knowledge is part of the developer's knowledgebase, the same concepts can be more intuitively applied in variable situations and with much less cost in requisite testing cycles.
"In order for the robustness of our spec compliant code to mean anything, I believe that we, our clients and their customers with disabilities must push harder for OS, user agent, and AT engineers to do their own bug checking during development, as well as after release. They need to have more skin in the accessibility game."
I agree, and this goes back to education, since it is impossible to reliably check for bugs when it's not clear what is being checked for and why. This was primarily the same topic I presented at CSUN about a couple of weeks ago regarding ARIA education:
https://www.linkedin.com/pulse/printout-using-visual-aria-physically-see-learn-how-works-garaventa
"Frankly, I think what will ultimately be required to move our cause forward by leaps and bounds, as Mike alludes to, are lawsuits that hold the software manufactures accountable for keeping their links strong to support the overall integrity of the chain of accessibility."
Unfortunately this can be a double edged sword, in that if we legislate mandatory accessibility, how do you do so by referencing a technical specification that is still and will always likely be in development, when the act of legislation sets requirements such as these in stone if applied to general law?
We saw this with Section508, the original of which is so obsolete at this point that we as developers cannot use it reliably for any specific guidance to make complex interactive web UIs accessible beyond the most basic markup enhancements.
My point is that ensuring legislation that supports accessibility is definitely a good thing, but it will likely be impossible to make laws that specifically apply to all OS, browser, and AT venders equally because all are not equal and these technologies are and will always be evolving into different entities that will outpace any technically explicit laws that may apply to them.