1.3.4 would be better under 3.3

[m-john-cha]

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.

[awkawk]

Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notification - How to limit notifications from GitHub

[DavidMacDonald]

[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

Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.

Response if we decide not to move 1.3.4 to 3.3.7

A 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.7

The 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 proposal

Response if we decide not to move 3.2.6 to 4.1.3

Although 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.
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 3.2.6 to 4.1.3

The 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.

[awkawk]

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.

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.

[Ryladog]

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.

[awkawk]

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).

[mbgower]

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.
I don't see a huge gain in moving either of these. They're not perfect where they are; they're not vastly better in the proposed locations.
What I would like to do is ensure that concerns with the limitations of the POUR model (if others share them) are passed along to the Silver group so we don't perpetuate the problem.

[Ryladog]

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)