From b74577873dbadc094f17495fbcc75f43460785c2 Mon Sep 17 00:00:00 2001 From: Melanie Sumner Date: Mon, 31 Jul 2017 17:00:18 -0500 Subject: [PATCH 1/4] Create 0000-aria-support.md --- text/0000-aria-support.md | 52 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 text/0000-aria-support.md diff --git a/text/0000-aria-support.md b/text/0000-aria-support.md new file mode 100644 index 0000000000..10fdec959e --- /dev/null +++ b/text/0000-aria-support.md @@ -0,0 +1,52 @@ +- Start Date: (fill me in with today's date, YYYY-MM-DD) +- RFC PR: (leave this empty) +- Ember Issue: (leave this empty) + +# Summary + +One paragraph explanation of the feature. + +# Motivation + +Why are we doing this? What use cases does it support? What is the expected +outcome? + +# Detailed design + +This is the bulk of the RFC. Explain the design in enough detail for somebody +familiar with the framework to understand, and for somebody familiar with the +implementation to implement. This should get into specifics and corner-cases, +and include examples of how the feature is used. Any new terminology should be +defined here. + +# How We Teach This + +What names and terminology work best for these concepts and why? How is this +idea best presented? As a continuation of existing Ember patterns, or as a +wholly new one? + +Would the acceptance of this proposal mean the Ember guides must be +re-organized or altered? Does it change how Ember is taught to new users +at any level? + +How should this feature be introduced and taught to existing Ember +users? + +# Drawbacks + +Why should we *not* do this? Please consider the impact on teaching Ember, +on the integration of this feature with other existing and planned features, +on the impact of the API churn on existing apps, etc. + +There are tradeoffs to choosing any path, please attempt to identify them here. + +# Alternatives + +What other designs have been considered? What is the impact of not doing this? + +This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. + +# Unresolved questions + +Optional, but suggested for first drafts. What parts of the design are still +TBD? From 221e612ca1da947badf66a8e054d4b216729b4ed Mon Sep 17 00:00:00 2001 From: Melanie Sumner Date: Mon, 31 Jul 2017 17:26:38 -0500 Subject: [PATCH 2/4] Update 0000-aria-support.md --- text/0000-aria-support.md | 50 +++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 26 deletions(-) diff --git a/text/0000-aria-support.md b/text/0000-aria-support.md index 10fdec959e..abfaa7ffa8 100644 --- a/text/0000-aria-support.md +++ b/text/0000-aria-support.md @@ -1,52 +1,50 @@ -- Start Date: (fill me in with today's date, YYYY-MM-DD) +- Start Date: (2017-07-31) - RFC PR: (leave this empty) - Ember Issue: (leave this empty) # Summary -One paragraph explanation of the feature. +Ember components currently only support the role attribute by default, with the ariaRole property. Better support for basic ARIA attributes would benefit developers who are required to support assistive technology as a legal requirement. # Motivation -Why are we doing this? What use cases does it support? What is the expected -outcome? +The motivation for the RFC comes from my work on a large UI component project in an enterprise environment. Because of the legal requirements for WCAG 2.0 AA conformance in my industry, I am always building in these properties to all of my components. I would prefer that Ember.component supports them by default, as it already does with ariaRole. # Detailed design -This is the bulk of the RFC. Explain the design in enough detail for somebody -familiar with the framework to understand, and for somebody familiar with the -implementation to implement. This should get into specifics and corner-cases, -and include examples of how the feature is used. Any new terminology should be -defined here. +In the same way that ariaRole is included in Ember.component, it would be useful to see three(3) other basic ARIA- attributes: +* ariaLabel = aria-label +* ariaLabelledBy = aria-labelledby +* ariaDescribedBy = aria-describedby # How We Teach This -What names and terminology work best for these concepts and why? How is this -idea best presented? As a continuation of existing Ember patterns, or as a -wholly new one? +It could be integrated into the API and presented in the same way that ariaRole is now. It gives a basic definition, links to the WAI-ARIA specification, and generally leaves it up to the developer to determine how to use it in a conformant way. -Would the acceptance of this proposal mean the Ember guides must be -re-organized or altered? Does it change how Ember is taught to new users -at any level? +## ariaLabel +aria-label defines a string value that labels the current element. Since only specific elements can successfully use aria-label, it is recommended to review the aria-label specification before using this property. +See https://www.w3.org/TR/wai-aria/states_and_properties#aria-label and https://www.w3.org/TR/WCAG20-TECHS/ARIA6.html -How should this feature be introduced and taught to existing Ember -users? +## ariaLabelledBy +aria-labelledby identifies the element(s) that labels the current element. It provides the user with a (machine) recognizable name of the object. The value should be the ID(s) of the element(s) that provide a label text. +See https://www.w3.org/TR/wai-aria/states_and_properties#aria-labelledby and https://www.w3.org/TR/WCAG20-TECHS/ARIA13.html -# Drawbacks +ariaDescribedBy: +aria-describedby identifies the element(or elements) that describe the object. It is generally intended to provide more verbose information. The value should be the ID(s) of the element(s) that provide this descriptive text. +See https://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby and https://www.w3.org/TR/WCAG20-TECHS/ARIA1.html + +While I would like to see some basic accessibility concepts included in the Ember guides, that is beyond the scope of this RFC. -Why should we *not* do this? Please consider the impact on teaching Ember, -on the integration of this feature with other existing and planned features, -on the impact of the API churn on existing apps, etc. +# Drawbacks -There are tradeoffs to choosing any path, please attempt to identify them here. +Possible drawbacks: +* Maybe there's some hyphen concern deep inside the Ember internals that would prevent this from happening. I can't say for sure since I have never had to dig that deep, yet. +* Performance: maybe Ember is already at some sort of perf tipping point and these would put it over the edge. # Alternatives -What other designs have been considered? What is the impact of not doing this? +The impact of not doing this is that developers who are trying to make conformant components will keep needing to add these same properties and using attributeBindings to attach them to their components. -This section could also include prior art, that is, how other frameworks in the same domain have solved this problem. # Unresolved questions -Optional, but suggested for first drafts. What parts of the design are still -TBD? From 8a4e613dfe7ae787c70ba19f116a018aa3efdcc8 Mon Sep 17 00:00:00 2001 From: Melanie Sumner Date: Mon, 31 Jul 2017 17:27:15 -0500 Subject: [PATCH 3/4] Update 0000-aria-support.md --- text/0000-aria-support.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/text/0000-aria-support.md b/text/0000-aria-support.md index abfaa7ffa8..1d84176d23 100644 --- a/text/0000-aria-support.md +++ b/text/0000-aria-support.md @@ -22,15 +22,18 @@ In the same way that ariaRole is included in Ember.component, it would be useful It could be integrated into the API and presented in the same way that ariaRole is now. It gives a basic definition, links to the WAI-ARIA specification, and generally leaves it up to the developer to determine how to use it in a conformant way. ## ariaLabel -aria-label defines a string value that labels the current element. Since only specific elements can successfully use aria-label, it is recommended to review the aria-label specification before using this property. +```aria-label``` defines a string value that labels the current element. Since only specific elements can successfully use aria-label, it is recommended to review the aria-label specification before using this property. + See https://www.w3.org/TR/wai-aria/states_and_properties#aria-label and https://www.w3.org/TR/WCAG20-TECHS/ARIA6.html ## ariaLabelledBy aria-labelledby identifies the element(s) that labels the current element. It provides the user with a (machine) recognizable name of the object. The value should be the ID(s) of the element(s) that provide a label text. + See https://www.w3.org/TR/wai-aria/states_and_properties#aria-labelledby and https://www.w3.org/TR/WCAG20-TECHS/ARIA13.html -ariaDescribedBy: +## ariaDescribedBy: aria-describedby identifies the element(or elements) that describe the object. It is generally intended to provide more verbose information. The value should be the ID(s) of the element(s) that provide this descriptive text. + See https://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby and https://www.w3.org/TR/WCAG20-TECHS/ARIA1.html While I would like to see some basic accessibility concepts included in the Ember guides, that is beyond the scope of this RFC. From 247c2b35c27f7298c08796aa8b3542f03a849513 Mon Sep 17 00:00:00 2001 From: Melanie Sumner Date: Mon, 31 Jul 2017 17:31:32 -0500 Subject: [PATCH 4/4] Update 0000-aria-support.md --- text/0000-aria-support.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/text/0000-aria-support.md b/text/0000-aria-support.md index 1d84176d23..ea82c929bc 100644 --- a/text/0000-aria-support.md +++ b/text/0000-aria-support.md @@ -17,6 +17,9 @@ In the same way that ariaRole is included in Ember.component, it would be useful * ariaLabelledBy = aria-labelledby * ariaDescribedBy = aria-describedby +## Note +This RFC is specifically requesting only these three, because the most common accessibility API mapping for a label is the accessible name property (covered with aria-label and aria-labelledby), and aria-describedby is the most typical accompaniament. + # How We Teach This It could be integrated into the API and presented in the same way that ariaRole is now. It gives a basic definition, links to the WAI-ARIA specification, and generally leaves it up to the developer to determine how to use it in a conformant way. @@ -27,16 +30,17 @@ It could be integrated into the API and presented in the same way that ariaRole See https://www.w3.org/TR/wai-aria/states_and_properties#aria-label and https://www.w3.org/TR/WCAG20-TECHS/ARIA6.html ## ariaLabelledBy -aria-labelledby identifies the element(s) that labels the current element. It provides the user with a (machine) recognizable name of the object. The value should be the ID(s) of the element(s) that provide a label text. +```aria-labelledby``` identifies the element(s) that labels the current element. It provides the user with a (machine) recognizable name of the object. The value should be the ID(s) of the element(s) that provide a label text. See https://www.w3.org/TR/wai-aria/states_and_properties#aria-labelledby and https://www.w3.org/TR/WCAG20-TECHS/ARIA13.html -## ariaDescribedBy: -aria-describedby identifies the element(or elements) that describe the object. It is generally intended to provide more verbose information. The value should be the ID(s) of the element(s) that provide this descriptive text. +## ariaDescribedBy +```aria-describedby``` identifies the element(or elements) that describe the object. It is generally intended to provide more verbose information. The value should be the ID(s) of the element(s) that provide this descriptive text. See https://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby and https://www.w3.org/TR/WCAG20-TECHS/ARIA1.html -While I would like to see some basic accessibility concepts included in the Ember guides, that is beyond the scope of this RFC. +## Note +While I would like to see basic accessibility concepts included in the Ember guides, that is beyond the scope of this RFC. # Drawbacks