Success Criterion 1.3.4 Purpose of Controls - Need to define THE list(s) and Conventional Name [Trace]

[GreggVan]

Success Criterion 1.3.4 Purpose of Controls§ Understanding Purpose of Controls(Level AA) [New] In content implemented using markup languages, the conventional name of conventional form fields, conventional buttons or controls, or conventional links can be programmatically determined.

Conventional Name also needs to be defined. Is it" CONVENTIONAL NAME - The name that is listed in the WCAG definition of the element type -- for example -- the conventional names for conventional links are the names in the conventional links definition.

You can do this - but you cannot have the definition of Conventional xxxx include of list of " conventional XXXX's that have been documented"

• you can say - this is THE list of conventional xxxxx's
• but by suggesting that these are only the documented ones -- and that there may be other ones -- you have made the SC untestable. I no longer know what you mean exactly and what other things do or do not qualify.

So you can fix this by saying it is THE list. (even though you may not want to limit this to what you know today) but otherwise it is not testable. And you cannot normatively refer to a list outside of the SC+definitions. (e.g. you cannot say in the standard or definition that the list of currently identified common controls is included at this URL where we will keep adding things as we identify them.

[DavidMacDonald]

This SC has had trouble, but if the COGA semantics take off it would be a good anchor for them. It doesn't require them because they are not in CR, but it paves the way for them. Authors can also just ensure they use the conventional names. (I wonder about internationalization).

Sounds like the team will need to buckle down and decide on the core list within the time frame of 2.1 which is perhaps 3-5 years. Most of the things on that list have a pretty long track record (i.e., first name). Personally I think the list should be less than 25, maybe 15 things. It's currently about 75 think.

[GreggVan]

This is not going to be in 2.1? but might be in 2.2? is that the message? (trying to decipher the CR comment above).

[DavidMacDonald]

This was approved to go towards 2.1 ... as with all of them... I assume it depends on comments and acceptance from stakeholders.

[johnfoliot]

Hi Gregg,

The list of Conventional Names needs better definition, no doubt about it. The current list was developed based upon a number of factors (one being the auto-complete feature/function found in most browsers). The small group of us who worked on this SC recognize that the list is likely way too long, which is why we published the draft seeking further feedback from the public on "whittling" it down.

As David notes, the intent here was that we took the original "Personalization" SC (which was driving towards the need to use COGA Semantics), and we broke it up so that we could then publish a AA and a AAA SC. This then paved a path towards using the Best Metadata schema, but left open the opportunity at AA to use any metadata schema (Schema.org, Microformats/Microdata, Dublin Core extensions http://dublincore.org/usage/documents/profile-guidelines/, etc.), or otherwise provide the required information a different way. The thought being that given that organizations and publishers will need to do something here for these critical components, that they'll do the right thing (which really won't be any harder than using any of the other methods), and use the robust metadata that COGA Semantics will provide. However, we can't specifically mandate the use of COGA Semantics at AA (we sort of do in the AAA companion SC), and so this is how we got to the current SC.

HTH

JF

On Sat, Sep 30, 2017 at 1:44 PM, GreggVan notifications@github.com wrote:

This is not going to be in 2.1? but might be in 2.2? is that the message? (trying to decipher the CR comment above).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/402#issuecomment-333328020, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-cxUlq7fytDD-gf6VNVVC2MAQWVp8ks5snovxgaJpZM4Pnnwb .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[GreggVan]

Thanks. Clear.

So in finishing this up we should focus on being sure that any list is THE list (i.e. a stable fixed list — so people can )
and not just examples (which leaves the person wondering if there are more that they MUST use) and a short list of the most important terms - terms that people would know - is more useful to authors, more likely to be used, and more helpful to users being sure that there are technologies out there that would support whatever techniques we are providing because without a sufficient technique that is supported by AT or access features in mainstream browsers — no one can conform and we can’t put it in the guidelines and - I guess - this would have to be true for all markup languages — or we would have to further constrain this to just HTML
since again we can create requirements that an author cannot meet

did I miss something?

tough road ?

g

Gregg C Vanderheiden greggvan@umd.edu

On Oct 2, 2017, at 9:35 AM, John Foliot notifications@github.com wrote:

Hi Gregg,

The list of Conventional Names needs better definition, no doubt about it. The current list was developed based upon a number of factors (one being the auto-complete feature/function found in most browsers). The small group of us who worked on this SC recognize that the list is likely way too long, which is why we published the draft seeking further feedback from the public on "whittling" it down.

As David notes, the intent here was that we took the original "Personalization" SC (which was driving towards the need to use COGA Semantics), and we broke it up so that we could then publish a AA and a AAA SC. This then paved a path towards using the Best Metadata schema, but left open the opportunity at AA to use any metadata schema (Schema.org, Microformats/Microdata, Dublin Core extensions http://dublincore.org/usage/documents/profile-guidelines/, etc.), or otherwise provide the required information a different way. The thought being that given that organizations and publishers will need to do something here for these critical components, that they'll do the right thing (which really won't be any harder than using any of the other methods), and use the robust metadata that COGA Semantics will provide. However, we can't specifically mandate the use of COGA Semantics at AA (we sort of do in the AAA companion SC), and so this is how we got to the current SC.

HTH

JF

On Sat, Sep 30, 2017 at 1:44 PM, GreggVan notifications@github.com wrote:

This is not going to be in 2.1? but might be in 2.2? is that the message? (trying to decipher the CR comment above).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/402#issuecomment-333328020, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-cxUlq7fytDD-gf6VNVVC2MAQWVp8ks5snovxgaJpZM4Pnnwb .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/402#issuecomment-333535768, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3rZyENoPRW4K73ajT1s-YJyXrviLks5soOaLgaJpZM4Pnnwb.

[joshueoconnor]

Relates to https://www.w3.org/TR/WCAG21/#purpose-of-controls

[awkawk]

In comment #341 @GreggVan suggested a definition for "conventional name": Conventional Name the name used in the "conventional form fields", "conventional buttons or controls", or "conventional links" lists respectively

[jake-abma]

Wrapping it up we have:

• Need definition for Conventional Name (Discussing this at #486 , #341, #570 and this issue #402)
• Being sure that any list is THE list (see also #426, https://github.com/w3c/wcag21/issues/427#issuecomment-343575766 and #570
• We have accessibility supported ways of conforming
• Has to be true for all markup languages (or constrain to HTML)

[GreggVan]

good list also be sure to not include names that are not really important — or that making standard might create problems. That is — solve the real problem but don’t create a new one by overextending. Very good summary

On Nov 17, 2017, at 4:05 AM, Jake Abma notifications@github.com wrote:

Wrapping it up we have:

Need definition for Conventional Name (Discussing this at #486 https://github.com/w3c/wcag21/issues/486 , #341 https://github.com/w3c/wcag21/issues/341, #570 https://github.com/w3c/wcag21/issues/570 and this issue #402 https://github.com/w3c/wcag21/issues/402) Being sure that any list is THE list (see also #426 https://github.com/w3c/wcag21/issues/426, #427 (comment) https://github.com/w3c/wcag21/issues/427#issuecomment-343575766 and #570 https://github.com/w3c/wcag21/issues/570 We have accessibility supported ways of conforming Has to be true for all markup languages (or constrain to HTML) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/402#issuecomment-345226714, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3nVOmBtS4a0aAZONyovFQjNzjtxMks5s3XaJgaJpZM4Pnnwb.

[joshueoconnor]

Looking at this thread, it looks like the discussion has been useful and there is work underway here - @GreggVan @jake-abma are you happy to close this?

[GreggVan]

I thought you had this one solved — until I heard that you now don’t mean that they terms in the list are the terms that need to be used — but rather that any set of terms can be used for those functions as long as they are documented somewhere. This is no way for this to meet “accessibility supported” if AT have no idea in advance what words to look for. If I create AT this year — and each month after release — for all years - a new site can use a new set of words — there is no way I can design my AT now to work with sites that use different sets of words that I don’t know what they will be. In order for this to work — you must tell me the functions AND the terms that will be used (or tell me that each technology will use a standard set of terms for that technology. (e.g. HTML will define the terms for HTML, PDF for PDF, etc.) Unless someone can tell me another way an AT vendor can know what the terms for those functions are in a programmatically determinable way.

On Dec 14, 2017, at 4:32 PM, joshueoconnor notifications@github.com wrote:

Looking at this thread, it looks like the discussion has been useful and there is work underway here - @GreggVan https://github.com/greggvan @jake-abma https://github.com/jake-abma are you happy to close this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/402#issuecomment-351842040, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3vSfuCeQju1Hwm4ZGleBM3SWxivHks5tAZPcgaJpZM4Pnnwb.cc

[jake-abma]

Hi @GreggVan,

I see new issues are added for your last remark(s) https://github.com/w3c/wcag21/issues/635 and https://github.com/w3c/wcag21/issues/636

To keep the issues in one place to discuss can we close this one?

Thanks, Jake

[GreggVan]

sure maybe add a reference back to the old so it can be easy found g

On Dec 18, 2017, at 6:38 AM, Jake Abma notifications@github.com wrote:

Hi @GreggVan https://github.com/greggvan,

I see a new issues are added for your last remark(s) #635 https://github.com/w3c/wcag21/issues/635 and #636 https://github.com/w3c/wcag21/issues/636 To keep the issues in one place to discuss can we close this one?

Thanks, Jake

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/402#issuecomment-352402315, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3s-1GUkivH2qdnB8axZfIVOjEx-8ks5tBk7TgaJpZM4Pnnwb.

[awkawk]

(Official WG response) Thank you for the comment. The SC has been changed to focus on currently supported attributes, so browsers support this across the board: https://caniuse.com/#feat=input-autocomplete-onoff (There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)

This aspect alone is very helpful to some people with cognitive issues.

For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already: Chrome extension: http://accessibility.athena-ict.com/personlization.shtml Script: https://github.com/ayelet-seeman/coga.personalisation Website based implementation: https://a11y-resources.com/developer/coga-personalisation

These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.

Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.

Given the user-need, and that this new version is far easier to implement, we hope that this addresses your concerns.