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

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

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.

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

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

Then we can remove the autocomplete bullet?

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.

David mentioned putting 1.3.4 under 4.1.

I don't think that that David was looking to move 1.3.4 to 4.1, just 3.2.6

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

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:

• The ability to add icons (i.e. adapt the interface)
• The ability to have suggested information automatically filled (i.e. input assistance)

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 aui-field attribute that passes the SC but does not trigger autocomplete features.

If it were in 3.3, doesn't it seem odd that you could pass the SC without providing any input assistance?

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 aui-field attribute, that funky stuff is still probably providing guidance on inputs elements though, right?

I've said the following points but haven't said them in this thread:

• the SC nowhere says the word "personalization". What it does talk about is "meaning" and programmatic determination.
• "Personalization" is not synonymous with the work of COGA. Pretty much any user, regardless of age or ability, could make use of it (though not necessarily in the way personalization is being envisioned or implemented by COGA). One thing the larger concept is very much akin to is the idea of Adaptable.
• the SC nowhere says you must implement autocomplete. In two places --in the opening line and the bullet about mapping to the Autofill field names -- it clearly says that this is about the meaning of the input fields.

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.

[Official WG response]
Thank you for the comment. We have broken this issues into two parts - #802 and #806. We have responded to both parts of your question, resulting in moving 3.2.6 to 4.1.3 but leaving 1.3.4 in place.

Please see these issues for further details.