WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible Mega Menu and Safari

for

From: Brooks newton
Date: Apr 4, 2016 11:39PM

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