Comments (6)
While
aria-disabled
does indeed not prevent you from clicking the button itself, it's important to understand whyaria-disabled
is used to begin with. There's a great article on CSS Tricks about it that's worth a read https://css-tricks.com/making-disabled-buttons-more-inclusive/.@jenewland1999 Thank you for the additional information.
In my opinion,
disabled
seems more appropriate thanaria-disabled
for common examples.The
aria-***
attributes will inform people using assistive technologies, such as screen readers, that such elements are not meant to be editable or otherwise operable.Unlike HTML's disabled Boolean attribute, which will communicate a form control as semantically being disabled, change its styling to reflect its state and suppress all functionality along with disallowing the element's value from participating in form submission, the aria-disabled="true" only semantically exposes these elements as being disabled. Web developers must manually ensure such elements have their functionality suppressed when exposed to the disabled state.
I don't disagree that the disabled
attribute is more common/familiar and likely easier for the examples because it gives intended behaviour. That said the follow up comments on PR #63852 suggest the intention might be purposefully to promote more accessible examples/docs.
That said it is a bit of a grey area.
from next.js.
While
aria-disabled
does indeed not prevent you from clicking the button itself, it's important to understand whyaria-disabled
is used to begin with. There's a great article on CSS Tricks about it that's worth a read https://css-tricks.com/making-disabled-buttons-more-inclusive/.@jenewland1999 Thank you for the additional information.
In my opinion,
disabled
seems more appropriate thanaria-disabled
for common examples.The
aria-***
attributes will inform people using assistive technologies, such as screen readers, that such elements are not meant to be editable or otherwise operable.Unlike HTML's disabled Boolean attribute, which will communicate a form control as semantically being disabled, change its styling to reflect its state and suppress all functionality along with disallowing the element's value from participating in form submission, the aria-disabled="true" only semantically exposes these elements as being disabled. Web developers must manually ensure such elements have their functionality suppressed when exposed to the disabled state.
I don't disagree that the
disabled
attribute is more common/familiar and likely easier for the examples because it gives intended behaviour. That said the follow up comments on PR #63852 suggest the intention might be purposefully to promote more accessible examples/docs.That said it is a bit of a grey area.
The suggestion in that pr also looks good. I will change and update soon
from next.js.
I fixed it and PR. #63888
from next.js.
While aria-disabled
does indeed not prevent you from clicking the button itself, it's important to understand why aria-disabled
is used to begin with. There's a great article on CSS Tricks about it that's worth a read https://css-tricks.com/making-disabled-buttons-more-inclusive/.
from next.js.
While
aria-disabled
does indeed not prevent you from clicking the button itself, it's important to understand whyaria-disabled
is used to begin with. There's a great article on CSS Tricks about it that's worth a read https://css-tricks.com/making-disabled-buttons-more-inclusive/.
@jenewland1999 Thank you for the additional information.
In my opinion, disabled
seems more appropriate than aria-disabled
for common examples.
The aria-***
attributes will inform people using assistive technologies, such as screen readers, that such elements are not meant to be editable or otherwise operable.
Unlike HTML's disabled Boolean attribute, which will communicate a form control as semantically being disabled, change its styling to reflect its state and suppress all functionality along with disallowing the element's value from participating in form submission, the aria-disabled="true" only semantically exposes these elements as being disabled. Web developers must manually ensure such elements have their functionality suppressed when exposed to the disabled state.
from next.js.
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
from next.js.
Related Issues (20)
- output export ssg generation for dynamic even with generateStaticParams id value is comming as %5Bslug%5D so page is not generated in build HOT 1
- Error: Invariant: attempted to hard navigate to the same URL
- Middleware Caches Uploaded Files In Memory
- "Module not found: Can't resolve" when using App router but works without error for Pages Router HOT 1
- req.url and req.nextUrl Show Docker Container IP/Port Instead of Real Host
- NextJS 14: Swiper only shows first slide HOT 1
- NextJS 14: Carousels only displaying first slide HOT 5
- revalidateTags is working localhost but not on vercel HOT 1
- Next.js/script empty strategy props not working in _document.js HOT 1
- next/script empty strategy props not working in _document.js
- Web Component Complex Values not working as expected on latest canary HOT 3
- [create-next-app, Yarn, linux/Darwin] Fresh Next projects can't be pushed to GitHub due to size of tracked @next/swc binary HOT 1
- Dynamic import trace in page source
- [React 19] Wrong `@types/react*` default version and build fails if the correct version is installed HOT 1
- Trailing slash on void elements HOT 1
- "Could not open page.js in the editor" error on VSCode Windows
- Docs: Minor syntax error in the streaming doc HOT 3
- Nextjs pages router doesn't update UI when using history replace HOT 2
- [turbopack] [next/og] monorepo fails to resolve workspace node_modules in root node_modules HOT 3
- create-next-app not working on newest version (14.2.3) with bun HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from next.js.