On our Jira board we have a custom field containing all the WCAG 2.1 success criteria, plus three additional entries: "None" (the default), "Triage" and "No SC". The latter is used in cases like this, or in cases where there is a significant UX problem for users with disabilities. However, to play devil's advocate, I would down-prioritise an issue like this, since it has zero impact on users, and even though the aria is misused, it does not fail any SC. One more point - when looking at an small issue like this it's easy enough to say "this is a trivial thing to fix", but in my experience, these kinds of issues are often created by misconfigured code generators, automated deployments and other scripts, rather than manual markup. It can sometimes be far from trivial to change a templating engine, or code generator, which has been tested and signed-off as working, even if the desired change is small. This is especially true when the org has political, infosec-related, technical or even legal constraints in place to reduce 'tweaking' of production code. These are not excuses, they are just the reality for larger scale deployments in certain sectors. We've had Language of Page issues that go unfixed for months because our content loads inside someone else's . It's trivial to add a language code to a static HTML page you made yourself. It's quite a different matter to run the gauntlet of corporate bureaucraciy *just to get permission* to tweak something that is built and maintained by another team, or (in some cases) another firm.
Love this video, and I look forward to more. I'm curious-do you know/are you able to tell us why a developer thought it made sense to apply aria-level in the first place? When I see broken ARIA I can usually guess what the developer's thought process was behind it, but in this case I'm at a loss.
Thanks for your lovely comment! I really don’t know. I guess it was copied from another example, maybe a tree view? I don’t think there was much active thinking behind it, especially as it was an outlier even in that project.
I'm not sure I follow the purpose of the video. I suppose if you want to nit-pick and see if the example exactly fails according to the specific wording of the success critieria, then one might say it's not a WCAG failure. The code fails the Nu Html Checker because of the invalid attribute, but as you said, an invalid attribute isn't in the list of four parsing errors. It probably should be (perhaps 4.1.1 should be updated to include that addition). But I don't know any accessibility expert that would *not* report this as a failure, and as @dennis said, it should be fixed. So back to my original comment, why is it important to have a video to show something people should never do and then justify that it's not a WCAG failure? That would seem to do the accessibility community a disservice.
Fair comment. And yes, I have argued that 4.1.1 should probably work more widely. On the other hand, it would have prevented us to use ARIA with HTML4 as that did not validate back in the day. I don't know how other people work, but sometimes you get explicit asks for WCAG conformance, especially in the context of lawsuits. I have also seen people push back on issues like this. Last but not least, if issues (like this) are inconsequential, they can prevent bigger issues from being addressed. Some people even might react negatively and get a bad impression of implementing accessibility when WCAG is used to argue for issues that have no actual impact. Also, I expect accessibility experts to read and interpret WCAG correctly. Report it as a bug, report it as a QA problem, but you cannot report it as a WCAG failure.
when there's a legal dimension, it can matter if something is ugly/broken code that has or hasn't got accessibility repercussions, and whether or not it hard fails WCAG or not. if it's the difference between "yeah, it's borked, but doesn't normatively fail" and "yes, you will get sued for this", it's worth being a bit more specific when something does or doesn't hard fail. and as eric says, nitpicking tiny bullshit like this helps nobody if it detracts from fixing issues that actually matter (i spent far too many hours with clients who obsessed about an absolutely trivial issue and getting that perfect, while the actual site/process at the macro level was completely broken. they latched onto the seemingly technically easy thing and ignored the far more fundamental "your entire site can't be used with keyboard/doesn't announce anything for AT users/something of similar critical importance)
Was about to say exactly the same as @Patrick Lauke here-an issue like this, while incorrect, is unlikely to impact a user in any way. Thus while it should be fixed, it should be lower priority than something that actually impedes a user. If it's deemed a WCAG failure then it immediately shoots up the priority list due to legal requirements, regardless of the actual impact on the user.
@@unomad112 and there's also the danger that if a client comes to you to do an audit because there's a legal dimension (they're getting sued or whatever), and you as an auditor flag something as a WCAG *fail* ... and it then later transpires that "oh, well, technically it's not a hard fail, but it's something you need to fix anyway", this immediately casts doubt in the client's mind on any other *fail*s that you told them about. And it can get even trickier if there are two or more auditors involved - one of them fails this, one of them passes but with note to fix ... leaves the client wondering why findings differ, and again then opens up a whole can of worms where clients need to be told that yes, some WCAG stuff is a bit subjective...which again can harm the client confidence. Anyway, it's all the stuff I rant about in th-cam.com/video/I0tghv881ac/w-d-xo.html so i'll stop here before reiterating my whole talk :)
On our Jira board we have a custom field containing all the WCAG 2.1 success criteria, plus three additional entries: "None" (the default), "Triage" and "No SC". The latter is used in cases like this, or in cases where there is a significant UX problem for users with disabilities.
However, to play devil's advocate, I would down-prioritise an issue like this, since it has zero impact on users, and even though the aria is misused, it does not fail any SC.
One more point - when looking at an small issue like this it's easy enough to say "this is a trivial thing to fix", but in my experience, these kinds of issues are often created by misconfigured code generators, automated deployments and other scripts, rather than manual markup. It can sometimes be far from trivial to change a templating engine, or code generator, which has been tested and signed-off as working, even if the desired change is small. This is especially true when the org has political, infosec-related, technical or even legal constraints in place to reduce 'tweaking' of production code. These are not excuses, they are just the reality for larger scale deployments in certain sectors. We've had Language of Page issues that go unfixed for months because our content loads inside someone else's . It's trivial to add a language code to a static HTML page you made yourself. It's quite a different matter to run the gauntlet of corporate bureaucraciy *just to get permission* to tweak something that is built and maintained by another team, or (in some cases) another firm.
Love this video, and I look forward to more. I'm curious-do you know/are you able to tell us why a developer thought it made sense to apply aria-level in the first place?
When I see broken ARIA I can usually guess what the developer's thought process was behind it, but in this case I'm at a loss.
Thanks for your lovely comment! I really don’t know. I guess it was copied from another example, maybe a tree view? I don’t think there was much active thinking behind it, especially as it was an outlier even in that project.
A good WCAG analysis, but it doesn't matter if it passes or fails; the code is totally wrong and should be fixed.
I do not disagree :-)
I'm not sure I follow the purpose of the video. I suppose if you want to nit-pick and see if the example exactly fails according to the specific wording of the success critieria, then one might say it's not a WCAG failure. The code fails the Nu Html Checker because of the invalid attribute, but as you said, an invalid attribute isn't in the list of four parsing errors. It probably should be (perhaps 4.1.1 should be updated to include that addition). But I don't know any accessibility expert that would *not* report this as a failure, and as @dennis said, it should be fixed. So back to my original comment, why is it important to have a video to show something people should never do and then justify that it's not a WCAG failure? That would seem to do the accessibility community a disservice.
Fair comment. And yes, I have argued that 4.1.1 should probably work more widely. On the other hand, it would have prevented us to use ARIA with HTML4 as that did not validate back in the day. I don't know how other people work, but sometimes you get explicit asks for WCAG conformance, especially in the context of lawsuits. I have also seen people push back on issues like this. Last but not least, if issues (like this) are inconsequential, they can prevent bigger issues from being addressed. Some people even might react negatively and get a bad impression of implementing accessibility when WCAG is used to argue for issues that have no actual impact. Also, I expect accessibility experts to read and interpret WCAG correctly. Report it as a bug, report it as a QA problem, but you cannot report it as a WCAG failure.
when there's a legal dimension, it can matter if something is ugly/broken code that has or hasn't got accessibility repercussions, and whether or not it hard fails WCAG or not. if it's the difference between "yeah, it's borked, but doesn't normatively fail" and "yes, you will get sued for this", it's worth being a bit more specific when something does or doesn't hard fail. and as eric says, nitpicking tiny bullshit like this helps nobody if it detracts from fixing issues that actually matter (i spent far too many hours with clients who obsessed about an absolutely trivial issue and getting that perfect, while the actual site/process at the macro level was completely broken. they latched onto the seemingly technically easy thing and ignored the far more fundamental "your entire site can't be used with keyboard/doesn't announce anything for AT users/something of similar critical importance)
Was about to say exactly the same as @Patrick Lauke here-an issue like this, while incorrect, is unlikely to impact a user in any way. Thus while it should be fixed, it should be lower priority than something that actually impedes a user.
If it's deemed a WCAG failure then it immediately shoots up the priority list due to legal requirements, regardless of the actual impact on the user.
@@unomad112 and there's also the danger that if a client comes to you to do an audit because there's a legal dimension (they're getting sued or whatever), and you as an auditor flag something as a WCAG *fail* ... and it then later transpires that "oh, well, technically it's not a hard fail, but it's something you need to fix anyway", this immediately casts doubt in the client's mind on any other *fail*s that you told them about. And it can get even trickier if there are two or more auditors involved - one of them fails this, one of them passes but with note to fix ... leaves the client wondering why findings differ, and again then opens up a whole can of worms where clients need to be told that yes, some WCAG stuff is a bit subjective...which again can harm the client confidence. Anyway, it's all the stuff I rant about in th-cam.com/video/I0tghv881ac/w-d-xo.html so i'll stop here before reiterating my whole talk :)