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.
>
>