WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility training and scanning solutions providers

for

From: JP Jamous
Date: Dec 17, 2016 3:28PM

Yeah and sometimes they flag elements with the same IDs when execution wise, those similar IDs would not cause an issue.

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

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.
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.