Editor form fields not 508 compliant if custom ID is used
Editor form fields not 508 compliant if custom ID is used
Hello,
I am using Editor and Datatables on a government intranet site and noticed that editor does not associate the label with an input field correctly if I specify a custom ID for the input field.
When I do this:
fields: [
{
label: "Name:",
name: "name",
attr: {id: 'name'},
},
{
label: "Position:",
name: "position"
}
]
The name field will not render the label and input in a way that is 508 compliant. The other field (in this example 'position') is 508 compliant.
You can view this behavior here: http://live.datatables.net/nuvihosi/38/edit?html,js,output
This question has accepted answers - jump to:
This discussion has been closed.
Answers
Hi @wblakenc ,
Thank you for the test case. Can you give some more information on why it isn't 508 compliant, please? That would help understand the issue better.
Cheers,
Colin
Sure. According to 508 compliance, form fields need to have a label that is paired up with the input field.
So this is compliant:
The form field and label are tied nicely together.
The above works and is 508 compliant if I do not add a custom ID (see blow or the use case), however when I add a custom ID editor does not use the ID I entered in the label tag. This causes the label to be orphaned and the input field to be 'missing' a label tag.
vs
Here is a link to the checklist I am using: https://webaim.org/standards/508/checklist#standardn another resource can be found here: https://webaim.org/standards/wcag/checklist#sc3.3.2.
I know that 508 is an US law that everyone should abide by but generally only the Government follows the law, so it might not be high on your priority to address. However, I wanted to let you all know.
Hi @wblakenc ,
Thanks for that reply, that makes it clear. I agree that's an issue. I've raised it internally (DD-1211 for my reference) and we'll report back here when there's an update.
Cheers,
Colin
@colin ,
Thank you! I appreciate it.
Hi,
Rather than using
fields.attr.idusefields.idwhich will allow this to work as expected.While it would be possible to check for
attr.idas well, it would mean there are two potential sources for the id, so I'd rather stick to the documentedfields.id, assuming that is suitable for you to use?Thanks,
Allan
@allen,
I must have missed that option. I thought the only way to add a custom ID was using the attr option. I will take a look, but if it works as you say, that solves my problem.
Thanks!
Hi @wblakenc ,
Yep, I missed that too. It seems to do the trick for me, see your updated example here.
Cheers,
Colin