My presentation on this topic focused on how people with disabilities use technology. Many developers and business decision makers don't get the "why" of accessibility because they don't use assistive technology or participate in the same usage patterns as people with disabilities.
For people who use keyboard navigation (low manual dexterity), a big problem I see is CSS overriding the default outline :focus style of the browser, so when someone uses tab to cycle through the interactive elements on the page, they can't see what is focused, and won't know what will happen when they hit enter.
On that same topic, the keyboard can't navigate to a custom "button," such as a span tag with an onClick event handler. The span won't receive focus, so someone using the keyboard can't activate that button.
Putting that in terms of a "BUY NOW" button that the user can't reach, I think is pretty impactful. Plus the number of ADA lawsuits for inaccessible websites tripled last year, so it's also a legal liability.
Custom buttons can recieve keyboard focus if they are built properly and implement the tabindex property on the HTML node and such.
I agree with your points, just figure that is a point worth clearing up - these things are often missed in custom elements, but can always be achieved.
You're right. The custom button element also needs a keydown event handler to respond to the user pressing the enter key while it has focus, and run the same code as the click event handler (or call click() on the element).
Keyboard accessibility can definitely be implemented on custom buttons, but considering how often it's not done properly (or at all), I figured it's probably easier for developers to just not do it. Thanks for mentioning this!
Another note, if the role attribute on a custom button isn't set to button it never appears in the accessibility tree. In general it's just a bad practice. I've never understood why someone would use a non-clickable element and try and force it to work as one anyway. Seems like way more work.
It sounds like we had very similar presentations! All of these are issues I see constantly on sites I review. Glad to see other folks taking notice and seeking to fix the problem.
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.
My presentation on this topic focused on how people with disabilities use technology. Many developers and business decision makers don't get the "why" of accessibility because they don't use assistive technology or participate in the same usage patterns as people with disabilities.
For people who use keyboard navigation (low manual dexterity), a big problem I see is CSS overriding the default outline :focus style of the browser, so when someone uses tab to cycle through the interactive elements on the page, they can't see what is focused, and won't know what will happen when they hit enter.
On that same topic, the keyboard can't navigate to a custom "button," such as a span tag with an onClick event handler. The span won't receive focus, so someone using the keyboard can't activate that button.
Putting that in terms of a "BUY NOW" button that the user can't reach, I think is pretty impactful. Plus the number of ADA lawsuits for inaccessible websites tripled last year, so it's also a legal liability.
Custom buttons can recieve keyboard focus if they are built properly and implement the tabindex property on the HTML node and such.
I agree with your points, just figure that is a point worth clearing up - these things are often missed in custom elements, but can always be achieved.
You're right. The custom button element also needs a keydown event handler to respond to the user pressing the enter key while it has focus, and run the same code as the click event handler (or call click() on the element).
Keyboard accessibility can definitely be implemented on custom buttons, but considering how often it's not done properly (or at all), I figured it's probably easier for developers to just not do it. Thanks for mentioning this!
Another note, if the role attribute on a custom button isn't set to button it never appears in the accessibility tree. In general it's just a bad practice. I've never understood why someone would use a non-clickable element and try and force it to work as one anyway. Seems like way more work.
It sounds like we had very similar presentations! All of these are issues I see constantly on sites I review. Glad to see other folks taking notice and seeking to fix the problem.