WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility training and scanning solutions providers

for

From: Lovely, Brian (CONT)
Date: Dec 19, 2016 6:41AM

The only time I would pass non-unique IDs is if the page is responsive and there is (for instance) the same header ID for desktop and mobile view but one is always hidden. Otherwise, it's not just bad coding but it can interfere with constructing the DOM or the accessible DOM.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of JP Jamous
Sent: Saturday, December 17, 2016 5:29 PM
To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Accessibility training and scanning solutions providers

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.
The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.