WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessibility training and scanning solutions providers

for

From: Birkir R. Gunnarsson
Date: Dec 19, 2016 7:23AM

When I was with Deque I wrote a blog on why unique ID ttributes matter
(based on a real case working with a real client).
http://www.deque.com/blog/unique-id-attributes-matter/



On 12/19/16, Lovely, Brian (CONT) < <EMAIL REMOVED> > wrote:
> 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.
> > > http://webaim.org/discussion/archives
> >
> > > http://webaim.org/discussion/archives
> > >
> 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.
> > > > >


--
Work hard. Have fun. Make history.