V8: Fix A & AA accessibility issues throughout the back-office #5277
Comments
|
Thanks to the wonderful work done by @BatJan, we now have a trello board which we will use to manage the progress of all of the issues below. ISSUES TRELLO BOARD - https://trello.com/b/AkmxU8xX/umbraco-accessibility-issuesFor information on how the audit was put together, please read this article by @RachBreeze - Improving the accessibility of the Umbraco CMS Backoffice The Umbraco Starter Kit was used a base project for the audit. As of 16th July 2019, the table below will no longer be updated in favour of using trello. Once everyone involved is comfortable with the new way of working, it will be removed. Striked out issues mean that they have been completed. This table is no longer updated
|
|
Here are some links to various tools and reference materiel should you require any help 🙂 Websites & Articles
Tools
Activate built in screen reader
|
|
PR for addressing 26 & 28 - #5304 |
ghost
mentioned this issue
|
PR for 4 - #5320 |
ghost
mentioned this issue
|
PR for 11 - #5333 |
|
PR for 19 - #5334 It's worth noting that many of these focus state bugs are related to there being specific |
Thanks for the great work Shane, as per the comments in your PR, I've updated the table with the PR submitted by @nielslyngsoe for 19. |
|
PR for 27 #5450 |
|
PR for 15, 16, 17 #5544 |
|
PR for 43, 69, 75, 81 #5585 |
|
Hi there :-) Issue 5: issue 6: Issue 7: That is the hover menu, right? That is a big blocker for keyboard users as well. issue 8: That isn't so much a case of unclear text as it is a case of missing aria markup, I would say. Adding aria markup to mark this button as expandable/collapsable pretty much fixes this. That is, if I understand the issue correctly; it is an actual button that behaves like a dropdown when clicked? issue 14: If escape doesn't close search, then yes that seems accurate. Then again, search appears at the bottom of the DOM, so unless it overlaps another element on the page directly often screen reader users won't even be aware search is open in the first place until they navigate all the way to the bottom of the page (screen readers follow the DOM for the most part when rendering HTML content). Issue 16: This is part of a larger issue where iconography is the only way to convey important information without textual alternatives. I see this all throughout the Umbraco UI, i.e. some menu options, buttons that change state (checkboxes) etc. and is actually one of the main entry barriers for screen reader users right now. Even a simple thing like following the basic website tutorial makes me have to guess at some things, as I am to " check the allow root" in the permissions tab of a new document type, which to me reads as a button with no text on it. issue 17: Can you elaborate on this? Aria-hidden is used to hide an item from the screen reader rendering, do you mean the icon should be aria-hidden and a textual sr-only span should be used to convey that this is the user icon? Issue 20: I am really sorry for the duplicate questions here but I am still very new to Umbraco. Is there another way to get at these children? If not, that is a serious blocker. Issue 22: sounds like a serious one, but I am not quite sure what it refers to exactly issue 25: I am unclear how an aria-role would fix this? You want the screen reader to say "Next" or " Continue" instead? That would require overriding the value of the control, not it's role. issue 29: Ditto to other similar issues. If there is no alternative way to access these options, that means it stops keyboard, screen reader and other assistive tech users right there and requires them to either ask someone for help or stop what they were doing. This is not acceptable in a lot of cases, especially in an employment situation. issue 32: This is the same problem as issue 16. The screen reader says "link" because that is the item's role, but the icon has no textual alternative, and is therefore not spoken. issue 33: That is another serious one, although in a pinch my suspicion is that a screen reader's virtual cursor commands might be of some use here. Need to test. issue 41: This is slightly related to issue 8. Controls don't have the right role; in this case that isn't supposed to be a button but a checkbox. You can either use a native HTLM element checkbox and get most of what you need for free, or add role=checkbox, aria-state toggled when the button is interacted with and keyboard handling code using JS. From a coding standpoint, just using a checkbox element would be preferable. However, this might introduce some browser-default styling that needs to be gotten rid of. issue 42: I think this mainly happens for checkboxes that only have an icon to denote their function. Also this has very little to do with form fieldsets, this is a name, role , value problem. issue 44: duplicate of issue 8? issue 46: That is problematic. Would refreshing the page help here? Asking to judge priority of this issue, not stating that that would be an acceptable workaround :-) issue 49: Same problem as 32 and therefore same as 16. Issue 51: That mainly breaks the non-happy path, e.g. user uploaded the wrong image and now can't get rid of it/change it. Issue 54: Is that the same issue as number 46? Same question about issue 55. issue 58: This is another pattern I see a lot as it were. It is not always clear to me, for example in the document type dialog, if I am editing a group, a property, what property I am working with etc. which makes that part of the interface very finicky to work with. E.g. I start changing editors for the wrong fields etc. This isn't as debilitating as some of the other issues but it is rather frustrating. issue 60: same as 16, 32 and 49 Issue 61: Is there a keyboard shortcut to activate this button instead? If not, that essentially means keyboard users can't write articles on the blog part. Serious blocker. Sounds to me like the recycle bin pretty much just isn't usable at all using a keyboard / screen reader right now. Issue 88: That basically means creators can't use media in their articles when they don't use a mouse. Serious showstopper. Issue 93: That is an interesting one. This is a big problem for people who want to create accessible content using Umbraco, which pretty much means it can't easily be used for public sector-based development, as not being accessible can have serious consequences in that space especially in the United States. issue 99: These options aren't reachable at all? Same question for 100. issue 102: This is not something an aria role can fix. An aria-labeledby perhaps. issue 105: That is why screen readers don't just tab through everything :-) IF there is textual content around interactive elements, it is up to the screen reader user to use alternative methods to read that information. Clear link text still applies, but static text does not need to be made tab-reachable here issue 111: same as 60, 49, 32 and 16. That is happening because there is just no meaningful content to report. issue 117: Seen this one pop up a few times in the list and figured I'd comment, that has to do with the fact that button has a unicode character on it that is called Left hand arrow". Probably this one, or a variation on it: ← issue 119: Haven't pointed them all out to keep this text somewhat within readable lengths, but this is a similar problem to 58 and there's a few more on this list like it. issue 122: I like this, this is essentially what I've been saying in regards to 16, 32 and friends. However, I think the icons here are not actual img tags, so an alt attribute wouldn't work here. You will probably want to aria-hide the icon and sr-only a label for them, or figure out some other strategy that makes the textual label accessible. Keep in mind that not just screen readers might want some kind of textual explanation; not everyone knows what a gear icon is supposed to mean especially if they aren't very computer-literate. issue 125: we've seen this one before as well. Wrong semantic role. See 41, for example. Again, haven't pointed all of these occurrences out but the pattern should be clear :-) issue 126: that really is a low-hanging fruit, as well as 133, 142 and 143 :-) issue 136: You guys are smart. You know what I am going to ask ;) issue 137: Lump this one in with the iconography problem Issue 144: That sounds like very broken HTML semantics to me. A div that is being used as a dropdown, perhaps. Although all this seems like a lot, targeted fixes can fix a reasonable majority of these issues relatively quickly (i.e. fixing one icon can set the path for fixing all of them and that knocks out about 10% of the issues already). |
|
Just wow All I can say is what an amazing and insightful post. This is some of the most useful information and you've been so thorough and given loads of detail. All I can say @zersiax is a heartfelt #h5yr and I really hope you can engage more with us as this project develops. There's so much to do and without posts such as yours, would mean that we may either misunderstand certain accessibility issues or we come up with fixes that actually give bad user experiences for those that they are intended. Hoping at some point that we'll have a catchup hangout soon and perhaps if you could attend and join in the conversation and provide any insight that could help on certain issues - but if you don't want to that's fine too - you've given loads of great info and I hope you'll help develop this project and give more! :) |
|
PR for issue 111 here #5970 |
|
PR added for issue 157 #6402 |
|
PR #6804 added for following issues:
P.S. I know the table needs some TLC. Once the fresh 8.2 audit is complete, i'll probably remove it entirely in favour of this trello board. https://trello.com/b/AkmxU8xX/umbraco-accessibility-issues If anyone has any alternative suggesstions/ideas/reservations please let me know. |
|
Another PR for fixing an issue with the media picker and keyboard accessibility. I think it may be the same at 46, but i'm not 100% sure. #6805 |
|
Hiya @MMasey, Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more. We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed). To open it this issue up again, you can write For example:
This will reopen the issue in the next few hours. Thanks, from your friendly Umbraco GitHub bot 🤖 🙂 |
IMPORTANT UPDATE
We have an updated trello board with all the tickets from the latest Accessibility Audit.
Trello Board for Umbraco Accessibility Issues (8.4>) - https://trello.com/b/7M8RosrE/umbraco-accessiblity-issues-84
Note - I've left the link for the old trello board for reference. We may close this ticket soon and open a new one to tidy things up a little bit.
There are currently a large number of accessibility and in tern usability issues throughout the back-office. One of the wonderful members of the PR team Danny Lancaster has created an accessibility audit, detailing each of the bugs found.
There are currently 151 known issues that need to be fixed. Rather than create an issue for each one, the idea is to do the following.
I've added some links to various articles and tools to help you on your way below. #5277 (comment)
If you have any questions you can reach out either here or on the Umbraco Community #accessibility Slack channel. You can join the community slack channel by going to umbracians.chat.
We have a Trello board with a list of resources and goals available at trello.com/b/MwD8xuz3/umbraco-accessibility
The text was updated successfully, but these errors were encountered: