-
Notifications
You must be signed in to change notification settings - Fork 779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inconsistent dlitem result depending on file extension #581
Comments
rdeltour
added a commit
to daisy/ace
that referenced
this issue
Dec 13, 2017
aXe v2.x uses an equality check based on the uppercase `tagName` property, but this latter is case-sensitive in XHTML. This change patches aXe until a PR is submitted to fix dequelabs/axe-core#581 Fixes #114
rdeltour
added a commit
to daisy/ace
that referenced
this issue
Dec 13, 2017
aXe v2.x uses an equality check based on the uppercase `tagName` property, but this latter is case-sensitive in XHTML. This change patches aXe until a PR is submitted to fix dequelabs/axe-core#581 Fixes #114
@WilcoFiers I spotted the issue and have a fix coming. It's only in the 2.x branch. I'll try to submit a PR today if you want to include it in 2.6! |
rdeltour
added a commit
to rdeltour/axe-core
that referenced
this issue
Dec 15, 2017
In XHTML, `element.tagName` preserves the case. In the `dlitem` check, the tag name is now upper-cased before being tested as 'DL', to make the rule work on XHTML documents. Fixes dequelabs#581
WilcoFiers
pushed a commit
that referenced
this issue
Dec 15, 2017
Should be fixed as of axe 2.6. Thanks @rdeltour |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
DT and DD elements are always flagged as not being contained in a DL element when they're inside a document with an xhtml extension, but not when in one with an html extension.
For example, these are identical documents, but only the latter generates an error:
http://matt.garrish.ca/res/pr01.html
http://matt.garrish.ca/res/pr01.xhtml
I believe this is a similar problem with nodeName as reported in #563
The text was updated successfully, but these errors were encountered: