RE: Alastair, Jan, Jason , myself and John have an updated version of

We’re still missing a definition of “conventional name”. To the extent that consensus has been reached in the discussion, I have tried to reflect it in the following first attempt.
Please note that the viability of this proposal as a whole depends on details that haven’t yet been worked out. Thus, I’m reserving judgment on that question until the details are decided. The issue before the group is whether we can agree on a version of this which is fit for public review and suitable to be further considered after August.

The conventional name of a user interface component

  *   Is expressed in the same natural (human) language as the label or instructions associated with the user interface component, and
  *   Is drawn from a published, controlled vocabulary of terms designating conventional user interface components.
The proposal discussed at the informal meeting today is that the conventional name could be simply included in the content (programmatically determined as the accessible name of the UI component) or provided using an accessibility-supported metadata format, a future ARIA extension, or whatever is most suitable.
I would like to see this proposal developed to the point at which we can fairly evaluate it and decide what to do with it in the course of subsequent work.

From: David MacDonald []
Sent: Friday, July 21, 2017 3:57 PM
To: John Foliot <>
Cc: lisa.seeman <>; W3c-Wai-Gl-Request@W3. Org <>
Subject: Re: Alastair, Jan, Jason , myself and John have an updated version of

In looking at Jason's proposal, I think it's more accurate.


The conventional name of every conventional user interface component can be programmatically determined.


Otherwise, it might be interpreted to mean the exact same thing as 4.1.2 which requires already that every component be programmatically determinable...

David MacDonald

CanAdapt Solutions Inc.

Tel:  613.235.4902



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

On Fri, Jul 21, 2017 at 2:18 PM, John Foliot <<>> wrote:
With the following draft definition added:
Draft list of Conventional Controls:
(note: we may be able to whittle this list down a bit - for a larger group discussion)

Form inputs:
·        name (corresponds to both first and family),
·        first name,
·        family name,
·        initial,
·        phone (corresponds to a user phone number),
·        cell phone,
·        address 1,
·        city,
·        state,
·        country,
·        post code,
·        credit card,
·        credit card security code,
·        dates: expiry date, birth date, today's date, date start, date end
·        calendar data: day, *month, *year,

Buttons or controls (content editing):
·        compose,
·        delete,
·        next,
·        previous,
·        submit,
·        undo,
·        cancel,
·        buy,
·        add label,
·        move,
·        view,
·        save,
·        send,
·        received,
·        sent,
·        edit,
·        reply,
·        forward,
·        my profile,
·        upload,
·        close,
·        more,
·        calendar,
·        entry,
·        expand,
·        unexpanded,
·        open,
·        new,
·        print,
·        settings,
·        mode,
·        higher,
·        lower.

Buttons or controls (navigation):
·        home,
·        contact us,
·        our phone,
·        our email,
·        site map,
·        help,
·        about us,
·        terms,
·        tools,
·        comment,
·        language,
·        sign in,
·        sign up,
·        product,
·        services,
·        social,
·        post,
·        contact us,
·        help,
·        chat help,

On Fri, Jul 21, 2017 at 11:20 AM, lisa.seeman <<>> wrote:
Hi Folks

Alastair, Jan, Jason and John have an updated version  of personlization support


Purpose of controls: In content implemented using mark-up languages, conventional controls can be programmatically determined. (AA)

we would like

In content implemented using markup languages, the function and context information of controls and regions can be programmatically determined using a publicly available vocabulary.

Upgrade and change 3.3.5 to AA -  Context-sensitive hel<>p is available for non-conventional controls  (this would included having a explanation)

All the best

Lisa Seeman

LinkedIn<>, Twitter<>

John Foliot
Principal Accessibility Strategist
Deque Systems Inc.<>

Advancing the mission of digital accessibility and inclusion


This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.


Received on Friday, 21 July 2017 21:47:26 UTC