[Athen] form elements

[Khoa Pham]

Karl,

This is great thank you again. Aside from the screen readers, AXE found ARIA attributes that were used incorrectly and on at other times these attributes had values that were considered to be invalid. Prior to bringing this error to the vendor's attention, I checked the WAI-ARIA Authoring Practices site to make sure that it's not a false positive and confirmed that it was an error. This is when they informed me of the modifications they had to make. 

-----Original Message-----
From: athen-list <athen-list-bounces at mailman12.u.washington.edu> On Behalf Of Karl Groves
Sent: Tuesday, October 23, 2018 6:45 AM
To: Access Technology Higher Education Network <athen-list at u.washington.edu>
Subject: Re: [Athen] form elements

On Mon, Oct 22, 2018 at 4:40 PM Khoa Pham <kpham at swccd.edu> wrote:


> Thank you very much for responding. Your response has definitely cleared things up for me. My understanding is if a developer follow the WCAG standards and WAI-ARIA best practice then there should not be any issues with contents when it comes to using different AT, such as JAWS and NVDA. Is this correct?

>


This is a bit of a strong assumption. True, there *should not* be any issues, but that isn't always the case.  It is a bit of a universal truth that software has bugs. AT is no different here. It is also inevitable that there will be cases where there is an inconsistency between how things should work and how they do work, with respect to a browser or AT's implementation of standards.  If anything, this proves the need to code to the standard. For instance, if the AT has a bug or has implemented something wrong, when they later go to fix it they will do so according to standard.


>

> The reason brought this question to the community is due to a response I had received from a vendor. When I brought some code such as the one in the original attached image and invalid ARIA codes, they said they had to modify or engineer the code in order for it to work with JAWS specifically. I didn’t believe them to begin with, but it seems they were adamant about their coding practices.

>


Making modifications due to issues with specific AT isn't unreasonable, but you're right to be suspicious.  Providing a proper <label> with a corresponding 'for' attribute mapped to the correct ID of the relevant form field is supported by all AT. It is the single most reliable mechanism of labeling fields.

In the vast majority of cases, when people say they had to create a "workaround" for JAWS, it is for one of two reasons 1. They don't actually understand how screenreaders work 2. They have some fundamental flaw in their code they can't really resolve without refactoring, so they put together fragile hacks


Karl






--
Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

www.tenon.io
_______________________________________________
athen-list mailing list
athen-list at mailman12.u.washington.edu
http://mailman12.u.washington.edu/mailman/listinfo/athen-list