Incorrect Reporting of: This element's role is "presentation" but contains child elements with semantic meaning.

[tmcconechy]

Working with our screen reader users we figured out we need to define our icons like this or they can get read buy IE / Certain browsers and this covers all cases

    <button type="button" class="btn-icon" title="Attach">
       <svg class="icon" focusable="false" aria-hidden="true" role="presentation">
          <use xlink:href="#icon-attach"></use>
       </svg>
       <span>Attach</span>
    </button>

However, starting recently this now reports: This element's role is "presentation" but contains child elements with semantic meaning.

Should it skip the case of SVG elements with only use tags?

[matejlednar]

I would like to ask about this issue too. We have now cca 300 role presentation errors - Dojo Toolkit widgets. Does your error checker work well?

[tmcconechy]

Thinking about this error. I cant think of any cases where this would be a error. If a developer decides to use role="presentation" then almost always 't they going to be hiding content/semantical elements for some reason.

http://www.w3.org/TR/wai-aria/roles#presentation

[matejlednar]

error sounds dangerous, maybe it should be classified as warning

[tmcconechy]

Yeah, Maybe warning. "Make sure your content under role='presentation' really doesnt have semantic meaning"

[matejlednar]

in this case it is generated by Dojo Toolkit framework, its widgets.

[robfentress]

I also get this incorrect error on tables marked as presentational, even though they do not contain semantic table elements like <th>, or <caption>, which might really be expected to trigger a valid error.

[sgregson]

I think the bug here is testing HTML elements which shouldn't be tested, not that the test is invalid. From the reference on https://www.w3.org/TR/wai-aria/roles#presentation

Many individuals erroneously consider role="presentation" to be synonymous with aria-hidden="true", and we believe role="none" conveys the actual meaning more unambiguously.

ie, role=presentation only negates semantics on that HTML element, not its children.

I was looking into the SVG issue and noticed that dropping role=presentation (to be only aria-hidden=true) removes the incorrect reporting, so I suspect it's coming from HTMLCS.js@2.1.1#L257. From that, the children of any node with role=presentation will get audited for semantics, regardless of whether it's been otherwise hidden from the Accessibility Tree.

@tmcconechy 's example would be addressed by tweaking the selector query of var presentationElems = topElement.querySelectorAll('[role="presentation"]'); to [role="presentation"]:not[aria-hidden="true"], but that doesn't cover other edge cases where aria-hidden could be set at a higher HTML element than the one using role=presentation. IMHO that's a pretty small edge case and the role=presentation shouldn't be assigned to children nodes of aria-hidden=true. Is there a more reliable way to check with HTMLCS whether the node is otherwise hidden from the AT?

@robfentress do you have some testable HTML? What you're describing sounds like a different root cause. Might be fixed by making the permitted whitelist of testSemanticPresentationRole element-specific 1_3_1.js#L107 I'd want a contributor to chime-in on whether that's the correct approach, however, before attempting to PR.

[ironikart]

Thanks @sgregson. I've updated with a small fix to test aria hidden on the element with role assigned and it's parent nodes.

The test for the issue @robfentress will require a little more research, but I suspect the expansion of the white list would be the simplest fix. If you'd like to submit a PR I'll assign some time to take a look at it.

[tmcconechy]

I'm still getting the same number of reports on the "bookmarklet" tool. http://squizlabs.github.io/HTML_CodeSniffer/

Is that updated (or takes a while to update)?

[ironikart]

Is that updated (or takes a while to update)?

We generally don't updated the bookmarklet until we've tagged a release so the currently bookmarklet code won't contain these fixes on the master branch. It's overdue so I'll organise a release with recent fixes in the near future.

[KittyGiraudel]

We have this problem on definition lists (dl) despite them not having aria-hidden or being child of an element with aria-hidden. Is it worth opening an issue regarding definition lists being incorrectly reported as presentational?

[ironikart]

@hugogiraudel Sure, it's worth opening an issue. Paste some example failing content and I'll look into it.