Nice work! Looks like you included a lot of functionality in a small space of time.
I’ve had a look at the demo in Safari on iOS and just wanted to suggest a few things:
The hamburger menu on the tasks page and the arrow to submit a task on the task creation page cannot be focused using a screen reader. I haven’t tried on desktop but it may be that these are not keyboard operable either. Idealy use a native <button> element. Otherwise, if these are custom buttons created from <div> or <span> elements or similar, you need to ensure they can receive DOM focus using tabindex=“0”. See the Mozilla tabindex article. Note that you will also have to build in the appropriate roles, states and device independent event listeners too. See Developing a Keyboard Interface in the WAI-ARIA Authoring Practices 1.2
The filter items in the navigation menu itself are not exposed as links. The iOS screen reader, VoiceOver, only announces them as plain text (I was able to open the menu, then turn the VoiceOver screen reader on to access these). Again, these are likely created using generic <div> elements so ideally use a native anchor element (<a href=“#”>) or add the ARIA role=“link”. If taking the latter approach you still need to build in the appropriate behaviours as previously mentioned.
Also, when viewing the demo, content behind the demo page is not hidden from assistive technologies. So I can still place screen reader focus (VoiceOver) on the landing page elements while viewing my tasks or creating a task. I saw others mention a modal so perhaps this fills the entire screen on iOS and elements behind are not hidden. One method is to use aria-hidden=“true” on a container that is a sibling of the modal container. You would also have to restrict keyboard focus. See the description of a modal in the WAI-ARIA Authoring Practices 1.2
Particularly on the create a task page, there appears to be poor contrast with the placeholder text and the button text. As a minimum you should aim for 4.5:1 for regular size text and 3:1 for larger size text (18pt or 24px / 14pt bold or 19px bold). See Contrast (Minimum) in the Web Content Accessibility Guidelines 2.1
Visually the buttons to complete tasks look like checkboxes so it is a little disorientating that the task immediately disappears when these are tapped. It would be clearer if visually these were more obviously buttons. However, the ability to select multiple tasks and then press another button to complete them would be a useful feature.
I would also say that it seems a bit counterintuitive that the back arrow is used to submit the task rather than cancel. I would either swap these buttons around so the arrow signifies forward progression, or ideally explicitly label it as ‘submit’ or similar.
Hi,
thanks you so much for taking the time to review my project and write all of this down. Let me check all the details and I will reply later.
Regarding the back button, usually the modal is closed when clicking outside of it. There is no save button, all changes are immediate. On small screens like a mobile phone, it is not possible to click outside, so I added the arrow button. Should I change it to close instead of the arrow to make it more intuitive?
So the arrow I’m referring to is the one used to submit the task. Personally i found it a little counter intuitive as being on the left and pointing to the left made me think it was a back button to dismiss the modal. The poor contrast on the grey cancel button also made it less obvious (ironically Dev.to has the same issue with their Preview button🙃)
I don’t think using an arrow is inherently wrong (So long as it had a text alternative such as using hidden text or an aria-label) although having a visible text label would remove any ambiguity, but I do think it would make more sense if the arrow was on the right and pointed to the right. The cancel button would then be on the left.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi,
Nice work! Looks like you included a lot of functionality in a small space of time.
I’ve had a look at the demo in Safari on iOS and just wanted to suggest a few things:
The hamburger menu on the tasks page and the arrow to submit a task on the task creation page cannot be focused using a screen reader. I haven’t tried on desktop but it may be that these are not keyboard operable either. Idealy use a native
<button>element. Otherwise, if these are custom buttons created from<div>or<span>elements or similar, you need to ensure they can receive DOM focus usingtabindex=“0”. See the Mozilla tabindex article. Note that you will also have to build in the appropriate roles, states and device independent event listeners too. See Developing a Keyboard Interface in the WAI-ARIA Authoring Practices 1.2The filter items in the navigation menu itself are not exposed as links. The iOS screen reader, VoiceOver, only announces them as plain text (I was able to open the menu, then turn the VoiceOver screen reader on to access these). Again, these are likely created using generic
<div>elements so ideally use a native anchor element (<a href=“#”>) or add the ARIArole=“link”. If taking the latter approach you still need to build in the appropriate behaviours as previously mentioned.Also, when viewing the demo, content behind the demo page is not hidden from assistive technologies. So I can still place screen reader focus (VoiceOver) on the landing page elements while viewing my tasks or creating a task. I saw others mention a modal so perhaps this fills the entire screen on iOS and elements behind are not hidden. One method is to use
aria-hidden=“true”on a container that is a sibling of the modal container. You would also have to restrict keyboard focus. See the description of a modal in the WAI-ARIA Authoring Practices 1.2Particularly on the create a task page, there appears to be poor contrast with the placeholder text and the button text. As a minimum you should aim for 4.5:1 for regular size text and 3:1 for larger size text (18pt or 24px / 14pt bold or 19px bold). See Contrast (Minimum) in the Web Content Accessibility Guidelines 2.1
Visually the buttons to complete tasks look like checkboxes so it is a little disorientating that the task immediately disappears when these are tapped. It would be clearer if visually these were more obviously buttons. However, the ability to select multiple tasks and then press another button to complete them would be a useful feature.
I would also say that it seems a bit counterintuitive that the back arrow is used to submit the task rather than cancel. I would either swap these buttons around so the arrow signifies forward progression, or ideally explicitly label it as ‘submit’ or similar.
Hi,
thanks you so much for taking the time to review my project and write all of this down. Let me check all the details and I will reply later.
Regarding the back button, usually the modal is closed when clicking outside of it. There is no save button, all changes are immediate. On small screens like a mobile phone, it is not possible to click outside, so I added the arrow button. Should I change it to close instead of the arrow to make it more intuitive?
So the arrow I’m referring to is the one used to submit the task. Personally i found it a little counter intuitive as being on the left and pointing to the left made me think it was a back button to dismiss the modal. The poor contrast on the grey cancel button also made it less obvious (ironically Dev.to has the same issue with their Preview button🙃)
I don’t think using an arrow is inherently wrong (So long as it had a text alternative such as using hidden text or an
aria-label) although having a visible text label would remove any ambiguity, but I do think it would make more sense if the arrow was on the right and pointed to the right. The cancel button would then be on the left.