I haven’t finished watching yet, so maybe this gets addressed, but disabled button states are something I think should be avoided. At minimum, a disabled button should still meet contrast guidelines, and remain focusable for screen readers (using aria to communicate that it’s inactive).
32:12 My first instinct while documenting focus order was referencing how the content is perceived - in this example that is H1 first and save button last, even though the save button is hierarchically the first element. But from what I learned from the course provided by W3C and also read on WCAG that the focus order should be top to bottom, left to right - no matter how the content is perceived because it may confuse people using screen readers. Wondering if anyone else had a similar experience?
You're not wrong. The issue here is the designed source order is not in a logical reading order. Instead of resolving this at the design level, the video recommends resolving it at the developer level in the source code order. It's not a great approach. Although the whole video is a triumph for integrating many aspects of accessibility into the design team.
This is so well explained. Thanks!
This is great content! I'm making my team watch this!
I haven’t finished watching yet, so maybe this gets addressed, but disabled button states are something I think should be avoided. At minimum, a disabled button should still meet contrast guidelines, and remain focusable for screen readers (using aria to communicate that it’s inactive).
Can you implement all the links in the description?
32:12 My first instinct while documenting focus order was referencing how the content is perceived - in this example that is H1 first and save button last, even though the save button is hierarchically the first element. But from what I learned from the course provided by W3C and also read on WCAG that the focus order should be top to bottom, left to right - no matter how the content is perceived because it may confuse people using screen readers. Wondering if anyone else had a similar experience?
You're not wrong. The issue here is the designed source order is not in a logical reading order. Instead of resolving this at the design level, the video recommends resolving it at the developer level in the source code order. It's not a great approach.
Although the whole video is a triumph for integrating many aspects of accessibility into the design team.
Can you be an accessibility tester without being a coder / developer?
For pure testing, where you're checking that success criteria are being satisfied, sure. Remediation work/advice will require deeper knowledge.