A client has run a course I made for them through ‘Access scan’ and it’s thrown back an issue Im not clear with. The element below came back with some fails (Ive also included a screenshot of some of the code snapshots it’s failed at).
‘aria-describedby and aria-labelledby attributes should reference the ID of an element that either has a text description or an “aria-label” attribute.’
Ive never come across this before. Anyone familiar with the issues? Some googling of the differences between labelled by and described by hasn’t really cleared it up for me and Im not sure it’s possible to distinguish these in evolve anyway?
All of the components used in the build have been given aria labels (except things like text and graphics).
hi @craigsteveid it’s difficult to tell for sure given just those screenshots but I’m going to take guess that it’s a automated accessibility test that’s flagging something that’s actually not going to have any impact on the learner whatsover.
In the box menu, if you have images on the menu items but don’t set alt text for the menu item image, Evolve will use aria-labelledby and aria-describedby to label the graphic by referencing other elements in the menu item, specifically the:
has a screen reader label of ‘View Components A to C’ and description of ‘This is the description for the page Components A to C’.
What I suspect is happening is that you have no description set for that page/menu item - and so the automated test is flagging that as an error because it has been poorly set up and so is not taking into account that the element already has a label via the menu item title (I’m assuming you have set a title) and therefore it doesn’t actually matter in the slightest that there’s no description set.
If your client absolutely insists this must be resolved then you can either add a description or add some alt text to the box menu item image.
I believe it was an automated test but I’ll check with them. Im not familiar with Access scan.
It also threw back this, Elements that act as buttons but use non-button tags (e.g., span, div, a) should include a role=“button” attribute.
The screen shot for these failure also included mention of the “ev-menu-item-view-button”, would that probably be the same thing?
Weirdly it also said this was a fail " Interactive elements that can be navigated using the keyboard should be surrounded by a visual outline whenever they are focused."
I had the focus outline on and can see that its on when I tab to an element so I was puzzled by that one.
And lastly this one " Elements that visually function as headings but are not coded with a heading tag should include a role=“heading” attribute or be updated to use the correct heading tag Element Heading levels should not be skipped and must follow a consistent hierarchy. For example, you should not use h2 and h4 headings without including an h3 in between"
it had a fail but I checked all of the heading tags with inspect and they seem to be correct.
Any experiences of automated tests throwing back these kind of errors?
If it is referring to the element ev-menu-item-view-button then it’s wrong to flag an issue with it: that element is a link to a page and therefore is correctly set up as an <a> element - and definitely does not need role='button' adding to it.
Automated accessibility tests are useful but only when the results are validated by a human accessibility checker as well to ensure that any ‘false flags’ get excluded…
