1.3.4 would be better under 3.3 #768
Comments
|
Thank you for commenting. For more information about how the AG WG will process this issue, see the following:
|
|
[Proposed unofficial response] We agree it could go in either place. I am drafting responses for both accepting and rejecting the comments and will take these back to the group for consideration. Move 1.3.4 to 3.3.7 proposal
Response if we decide not to move 1.3.4 to 3.3.7A core intention of this SC is personalization, including the idea that tools will be able to insert icons and adapt the page based on these values. It is also moving towards simplifying the page because a tool may be used to simplify the page based on these values. We feel that these reasons in addition to the administrative overhead of changing the location of this SC, make the value of changing not worth the cost and value of moving it. Response if we decide to move 1.3.4 to 3.3.7The Success Criteria has changed over iterations, and we agree that many of the previous reasons to include it here are not found in the current wording of the SC, therefore we will move it to 3.3.7 as proposed. Move 3.2.6 to 4.1.3 proposalResponse if we decide not to move 3.2.6 to 4.1.3Although a lot has been removed from previous iterations of this SC that warrants its placement here, we feel that this requirement helps the interface operate in predictable ways for screen reader users. Response if we decide to move 3.2.6 to 4.1.3The Success Criteria has changed over iterations, a lot has been removed from this SC that would warrant its placement here anymore. We agree that it would be better next to its cousin SC (4.1.2), and have relocated it to 4.1.3as proposed. |
|
As I indi 8000 cated in an email to the list, I don't like the idea of moving 1.3.4 to 3.3.x because it is our first crack at personalization and 1.3.5 makes much more sense in concert with 1.3.4, and 1.3.5 doesn't belong in 3.3 because it doesn't deal exclusively with inputs. 1.3.4 is also not just about input assistance. It is also about identifying what the input is about and allowing users to use tools to adapt the appearance of that information. That said, the reason to adapt it is for understanding, so the Understandable principle also makes sense, but if so I would rather see it in 3.1.x ("Make text content readable and understandable") but that has the downside of using "text" in the guideline text, which isn't ideal. I would prefer to keep 1.3.4 where it is unless we can justify moving it to 3.1. For 3.2.6 I can go either way. |
|
AS 1.3.4 has been reduced to be mostly about autocomplete, and not what the
identified original Purpose of Controls that was brought to us by the task
force, I believe this SC is about helping users to complete common form
data, and therefore belongs under 3.3 Input Assistance.
|
|
I don't think that 1.3.4 is "about autocomplete" - it is using the defined values under autocomplete to provide a set list of values to drive the identification and personalization (and autocomplete). |
|
My perspective on this is that the POUR model and its guidelines are not adequately normalized. As a result, each new SC that is added increases the chance of an uncomfortable fit and further reduces the model's usefulness. |
|
Then we can remove the autocomplete bullet? This SC has changed markedly
from the original intended purpose, and its primary functional purpose for
implementation today, is about helping people, with memory and cognitive
issues to complete/fill-in a form using the autocomplete attribute function
of HTML 5.2. So, I disagree. It is best fit under 3.3.
(AWK edited to remove extra text in Katie's post as a result of replying via email)
|
|
I agree with Andrew. My suggestion is to simplify the response "We feel that these reasons in addition to the administrative overhead of changing the location of this SC, make the value of changing not worth the cost and value of moving it." to "We feel that these reasons, in addition to the administrative overhead of changing the location of this SC, outweigh the value of moving it to 3.37." Likewise for 3.26. |
|
As I said on the call, I don't think there is a correct answer for 1.3.4 over time: Right now the main user-benefit is from autotcompleting fields, with a potential (but un-proven) benefit for adding icons (or other aspects) for personalisation. A couple of years hence it might be the other way around. When udpating the understanding doc I tried to reflect that. (I'm just checking with Lisa before replacing the currently linked one.)
That's the content requirment, without that there is no action to do or testability. Regardless of which user-benefit anyone thinks is primary, that's the content requirment that fulfills both. David mentioned putting 1.3.4 under 4.1. I'm not keen on this, I think it makes sense for people very familiar with ARIA so have an association with 4.1.2. However, for general developers designers it feels like putting alt-text under 4.1 beacuse it is about adding an attribute. I lean towards putting it under 3.3 Input assistance, as by the time the personalisation aspect is popular/proven we'll probably be moving onto Silver (fingers cross, no inside info etc.) However, I can live with it where it is, and I'd rather just make a decision. @awkawk maybe I could make survey with that ranking selector that Michael showed me? ;-) For 3.2.6, I'm fairly ambivilent, it makes sense under either which indicates the categories need work, but that's beyond the scope of 2.1. |
I don't think that that David was looking to move 1.3.4 to 4.1, just 3.2.6 |
|
As I indicated in an email to the list, I don't like the idea of moving 1.3.4 to 3.3.x because it is our first crack at personalization and 1.3.5 makes much more sense in concert with 1.3.4, and 1.3.5 doesn't belong in 3.3 because it doesn't deal exclusively with inputs.
1.3.4 is also not just about input assistance. It is also about identifying what the input is about and allowing users to use tools to adapt the appearance of that information.
+1 to Andrew.
The use of @autocomplete is but one Technique towards meeting the intent of SC 1.3.4, and protracted discussions around using that technique is IMO unhelpful in the context of the *content*, *intent *or "
*numbering/placement*" of this particular SC.
The language of the current SC is focused on "grammatically determinable", and is not about explicitly using @autocomplete, any more than than SC 1.1.1 mandates the explicit use of @alt - it's a leap of reasoning that is incorrect and unsubstantiated (as to meet SC 1.1.1 I can also use one of aria-label, aria-labeledby, or even @title (poorly supported but not forbidden https://www.w3.org/TR/2014/REC-wai-aria-implementation-20140320/#mapping_additional_nd_description_header - see bullet 2-D))
JF
(AC: Edited to remove extra email stuff and improve formatting)
|
I thought that's what David said on the call, maybe not, never mind. I'm not particularly arguing about the technique used (in terms of placement), but the POUR categories are essentially about the user-benefit of the guidelines/SC. In this case it is easier to make an argument about input-assistance than adaptation. This basic point crosses over to the Understanding doc discussion, so I'll try to make the case one last time:
I'm just worried that presenting this now as primarily about personlisation will create issues pre-publication. |
|
Alastair,
This commenter has made good points.
I do completely agree that for 1.3.4 we need to support the primary use of
this SC as is, to help users with memory problems when completing forms.
The name of the SC should be changed to reflect that. The placement of the
SC should be moved to 3.3 Input Assistance.
And the Understanding doc should start with addressing the current primary
purpose of this SC.
Then, this WG can begin working with the wider web community to prepare a
personalization SC, for a future iteration of this standard when the
technology has matured. WCAG does not need to try to push the envelope on
this web-wide issue. That needs a more comprehensive effort and track.
We need to provide solid implementable for solutions to address the user
needs we said we would address.
I fear a half-baked SC will damage the possibility of uptake of other
clearly useful SCs.
Rather than appearing innovative, I fear that providing rationale that is a
stretch technologically today, and without consulting and working with
other stakeholders on personalization will cause this WG and our work to
lose credibility.
AWK said: "...1.3.4, and 1.3.5 doesn't belong in 3.3 because it doesn't
deal exclusively with inputs."
KHS: And yet the 1.3.4 SC text starts out as "The meaning of each input
field..."
We have gone far afield, and the maturity is not there to support this
other that for cognitive decline memory issues.
Katie
…On Mar 7, 2018 6:04 PM, "Alastair Campbell" ***@***.***> wrote:
I don't think that that David was looking to move 1.3.4 to 4.1, just 3.2.6
I thought that's what David said on the call, maybe not, never mind.
I'm not particularly arguing about the technique used (in terms of
placement), but the POUR categories are essentially about the user-benefit
of the guidelines/SC. In this case it is easier to make an argument about
input-assistance than adaptation.
This basic point crosses over to the Understanding doc discussion, so I'll
try to make the case one last time:
- The SC started as a means of applying personalisation;
- The custom attributes weren't considered mature enough (and now I
understand the timetable better, I agree!)
- Narrowing it down to only use the same values as autocomplete takes
it to 5, 10%(?) of the original intent. That's why Lisa commented that it
wasn't supporting personalisation.
- If a user-agent (e.g. the a11y-resources
<https://a11y-resources.com/developer/adaptable-ui-personalisation#aui-field>
site wants to support personalisation, the small set of attributes this SC
covers is almost a second thought, it wouldn't be enough to justify an
extension (for example).
- By using autocomplete tokens, the SC happens to have enabled another
user-need, preventing errors.
- The basic content requirement is the same in each case.
- COGA TF are happy that this is still a useful & valid SC for people
with cognitive impairments.
I'm just worried that presenting this now as primarily about
personlisation will create issues pre-publication.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#768 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyiOOvKruN93jyyM0hzWKLQEFn01Kks5tcGdugaJpZM4SCPa7>
.
|
|
Given that the POUR categorization tends to fall down when something could go in multiple places (like any single-method categorization), my feeling at the moment is that this comes down to what prioritization people are giving to the two identified user benefits:
Whichever of these you think is primary (for various reasons) determines where you think it should go. However, there is a technical point: The SC can be fulfilled with autocomplete, or with other attributes. If someone uses the If it were in 3.3, doesn't it seem odd that you could pass the SC without providing any input assistance? |
Even if an author does some funky stuff with the I've said the following points but haven't said them in this thread:
Does it fit better in its current form under Input Assistance? I'd say yes. Is it confusing under Adaptable? I'd say not especially. If we go up to the principle level, it seems to make more sense under Understandable than Perceivable. Given those two things, I think there is a good case to move it. Given the points above, I don't find the argument persuasive that moving it nullifies its long-range intent. Personalization (in whichever sense you mean it) can be served in a variety of WCAG Principles and Guidelines. But @kwahlbin et al, if we did move 1.3.4 to Input Assistance, where would you put 1.3.5? I'm opening a new issue that lists all the items I flagged back in December because if we're going to move one thing, I think we should do a full analysis of the new ones and put them in the best places. |
|
Mike,
I agree, I think we need that full analysis of all the new ones and their
placement. I would decouple current 1.3.4 from 1.3.5 completely. Current
1.3.4 needs a new name about helping users with memory issue to fill in
form inputs. 1.3.5 could stay where it is, as it would e decoupled. My 2
cents.
** katie **
*Katie Haritos-Shea*
|
|
Even if an author does some funky stuff with the aui-field attribute,
that funky stuff is still probably providing guidance on inputs elements
though, right?
Only in the most abstract definition of "guidance" (where overlaying an
icon "guides" users to better understand what *value* the form input is
truly seeking). And while Alastair has noted potentially using the newly
minted aui-* attributes as a different mechanism for making inputs
**programmatically
determinable** (and remember folks, that's what the SC requires), the
Personalization TF have also suggested using other methods
<https://w3c.github.io/personalization-semantics/#mapping-values-to-different-syntax>
for
attaching metadata to those inputs, including Microdata and RDFa (and both
of those techniques are not restricted to any one metadata schema either).
[alt: screen capture from https://a11y-resources.com/developer/adaptable-ui-
personalisation#aui-field showing an icon overlay on a form input -
indicated with a red arrow]
Mike, I could use similar arguments to suggest moving *1.4.12 Text Spacing*
under a 3.x.x SC, as with better spacing the content is more readable
(legible) and thus more Understandable, or moving *2.4.12 Label in Name*
under a 1.x.x SC, as ensuring the name is in the label makes it easier to
Perceive for all users (and 'round and 'round we could go...). I believe
that most of us understand that for many of WCAG's SC (new and old), they
don't always neatly fall under one single Principle, and stressing-out to
determine which Principle is *better* supported just feels kind of silly to
me - to my mind they are supporting PEOPLE first, not Principles.
I think we should do a full analysis of the new ones and put them in the
best places.
I will respectfully suggest that the time for that activity has long since
passed (i.e. it should have happened before CR). We have roughly 100
days between now and when we must publish WCAG 2.1, with a number of
time-sensitive issues still to be resolved, and rearranging deck chairs on
the WCAG 2.1 ship is (IMHO) not the most pressing task before us.
All of the emergent SC have been 'rooted' under their respective Principles
throughout multiple publishing iterations, and I personally fail to see the
value in disrupting the momentum we've been working under since we first
published our FPWD for *little real value to end users*.
*OFFICIAL REQUEST*
Chairs, can we put this perma-thread to bed please? I personally would
strongly support an internal CfC on whether or not we move this SC under
"Understandable", at the same time noting that the W3C Process
<https://www.w3.org/2018/Process-20180201/#Consensus> does not allow
objections to block progress. It is my opinion that we need to move on to
more important issues (like finalizing our new Understanding documents,
collecting and collating Techniques, and ensuring we have working examples
for all of our new SC, which our call on Tuesday suggests we're far from
completing today).
JF
…On Thu, Mar 15, 2018 at 9:45 AM, Katie Haritos-Shea < ***@***.***> wrote:
Mike,
I agree, I think we need that full analysis of all the new ones and their
placement. I would decouple current 1.3.4 from 1.3.5 completely. Current
1.3.4 needs a new name about helping users with memory issue to fill in
form inputs. 1.3.5 could stay where it is, as it would e decoupled. My 2
cents.
** katie **
*Katie Haritos-Shea*
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#768 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c5u9jBZH4MYhUOq747ctjHEilzYJks5ten6DgaJpZM4SCPa7>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com
Advancing the mission of digital accessibility and inclusion
|
I think SCs 1.3.4 and 3.2.6 could be better placed than they are right now.
1.3.4: I see the argument for putting it under 1.3, but fundamentally, this SC is about ensuring that users are able to understand the purpose of input fields, and it is much closer to the 3.3.x SCs than anything under 1.3.
(Editors note, the following section has been moved to #802 please comment/discuss there)
3.2.6: Again, there is some validity for putting it under 3.2, but the main thrust of this SC is making sure that status messages are compatible with AT, the same way that 4.1.2 ensures that names, roles, and values are compatible with AT.
The text was updated successfully, but these errors were encountered: