WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility training and scanning solutions providers

for

From: Birkir R. Gunnarsson
Date: Dec 17, 2016 1:51PM

I don´t like checkers that automatically flag use of ARIA as a failure
and stop checking. I see this in quite a few checkers.
The checkers need to understand ARIA and check if ARIA is being used
according to spec (because correctly used ARIA can imporve the user
experience, and it is a fully valid coding technique according to a
W3C standard).

I am fine with checkers flagging a warning that HTML has an element
that can do the same, but it shouldn´t be flagged as an error.


On 12/17/16, JP Jamous < <EMAIL REMOVED> > wrote:
> 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.
> > > http://webaim.org/discussion/archives
> >
> > > > >


--
Work hard. Have fun. Make history.