WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility training and scanning solutions providers

for

From: JP Jamous
Date: Dec 17, 2016 1:19PM

I second Birkir on this one. I deal on daily bases with old code dated back to 2005.

I butt heads with UX teams because they get their analytics and they have zero information about people with ATs. That is why I trying to make changes to ensure we have the best user experience on our site.

Being a software and web developer in the past, I don't rely much on automated checkers. I want to test drive that sucker myself and get the user experience. Even iOS and Android emulators I try to stay away from. I want the actual device and I want to be on a fully opened network rather behind a proxy firewall.

All of the above, I learned that they can block what the customer experiences during a session. I want to be in that person's shoe despite the disability and get a feel for what is happening. I then do the automated checking.

I know I am weird, but I want to achieve 2 things.

1. Is the site providing an accessible and positive user experience?
2. How can I prioritize my work and establish proper documentations for developers based on what I am experiencing so they can remedy the issues.

If I am still getting some issues in the automated checker but the performance is excellent, then move on JP. That's how I like to approach those tasks. Relying on a program to make sense out of a pot of old, new and sloppy coding can frustrate the best decision maker. Of course, the checker will fail too many things.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: Saturday, December 17, 2016 1:43 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

Well, at the end of the day it is all about whether the user can have an accessible experience (ideally not just accessible, but also usable).
That all comes down to how the website is designed and only partially down to how it is coded.
I think e.g. that dynamic forms are a very good user experience if done corectly.
By dynamic I mean forms that show you information and fields based on your selections.
Imagine a set of radiobuttons. For each radiobutton you choose you'd get a different set of form fields.
A poorly static html page would show you all of the fields for all choices. Even if this form were perfectly marked up for accessibility it would be cumbersome and confusing to fill in.
A dynamic form that only displays the info you need to fill in as you select a radiobutton provides amuch better user experience, but it requires CSS/JavaScript to make it happen.
Basically, if people avoid unnecessarily using ARIA and JavaScript and use the HTML element most appropriate for the purpose, I am happy.
HTmL does not have all the answers (dynamic forms, live regions, tab and menu constructs, modal dialogs, auto complete searches cannot be implemented with HTML alone, HTML5 is moving us closer but we're still far off).
People who build custom elements as a rule always get themselves in trouble, because they don't understand all the nuances and complexities of assistive technologies. Even if they do, the browsers and a.t. themselves do not always know how to interpret the markup.
But people who think of JavaScript/ARIA as inherently inaccessible an evil, and believe the web should still be coded using HTmL only are not providing the users with the best experience

It's all about the the situation, the content and the desired user experience.



On 12/17/16, L Snider < <EMAIL REMOVED> > wrote:
> Hi Birkir,
>
> What has been your experience if the DOM passes, but the HTML has been
> a mess, in terms of user testing? I have seen people do what you
> suggested, basically layer over the html, but I always wondered how
> people found it in terms of accessibility, and not just a checker
> saying it is okay. If that makes sense?
>
> For me, I want the DOM and HTML to be accessible, as much as possible.
> but I found others I have met in the past few years don't always share
> that view-and they rely on the DOM to fix the issues, when if they
> just worked on the HTML...well you can see where I am going with this!
>
> Cheers
>
> Lisa
>
>
>
> On Fri, Dec 16, 2016 at 12:03 PM, Birkir R. Gunnarsson <
> <EMAIL REMOVED> > wrote:
>
>> Karl Groves set up the provocatively named but brilliant
>> http://www.mothereffingtoolconfuser.com
>> This is a webpage whose HTML source code has a number of
>> accessibility issues, all of which are fixed with JQuery that runs on page load.
>> So the HTML source has a bunch of issues, the DOM should have 0.
>> If a tool reports a bunch of errors on this page, either it tested
>> the HTML source, or there is something happening with JavaScript not
>> running (I have seen it happen when trying to test this page from
>> behind a corporate firewall).
>> But if the tool reports 0 errors, it is testing the DOM.
>> I had a SiteImprove tech guy test this page for me (in SiteImprove
>> you cannot test a random page yourself,only the domain you have
>> access to). He said it returned 0 errors, Based on that info they
>> test the DOM.
>>
>> -B
>>
>>
>> On 12/16/16, Sean Keegan < <EMAIL REMOVED> > wrote:
>> > Hi Peter,
>> >
>> > Have you verified with SiteImprove that the tool does not check the DOM?
>> I
>> > raised this question with two different technical people at
>> > SiteImprove several months ago and both said the tool is evaluating
>> > the DOM, not the source code.
>> >
>> > Take care,
>> > Sean
>> >
>> >
>> >
>> >> ---------- Forwarded message ----------
>> >> From: "Bossley, Peter A." < <EMAIL REMOVED> >
>> >> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> >> Cc:
>> >> Date: Wed, 14 Dec 2016 19:16:11 +0000
>> >> Subject: Re: [WebAIM] Accessibility training and scanning
>> >> solutions providers Siteimprove doesn't appear to actually test
>> >> the DOM, so I bounced them
>> off
>> >> the list for that one alone.
>> >>
>> >>
>> >>
>> > >> > >> > archives at http://webaim.org/discussion/archives
>> > >> >
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.