You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.
In content implemented using markup languages, the conventional name of conventional form fields, conventional buttons or controls, or conventional links can be programmatically determined.
It's not clear to me what are the implications of this SC, nor how one actually follows this advice. Following the links leads to lists such as https://www.w3.org/TR/WCAG21/#dfn-conventional-links. Are those terms in bold meant to be literal strings in the UI/markup? (If so, there's a big i18n issue.) How are they supposed to be detected/used? An example would help.
The text was updated successfully, but these errors were encountered:
We are also not saying content authors should use literal strings which create the i18n issues but that its role as a control should be programmatically determinable. It is just for programmatic identification (so AT can identify them or autofill can work and other support) — but we are not requiring that they be the terms used for users to see.
Does this sufficiently answer your concern? If not please let us know and we'll be happy to respond!
Success Criterion 1.3.4 Purpose of Controls§
https://www.w3.org/TR/WCAG21/#purpose-of-controls
It's not clear to me what are the implications of this SC, nor how one actually follows this advice. Following the links leads to lists such as https://www.w3.org/TR/WCAG21/#dfn-conventional-links. Are those terms in bold meant to be literal strings in the UI/markup? (If so, there's a big i18n issue.) How are they supposed to be detected/used? An example would help.
The text was updated successfully, but these errors were encountered: