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

Hi everyone,

Lisa wrote:
> FYI the current wording is:
> In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined. (AA)

That’s a slight tweak to what we discussed in the call but a good one.

I suggest the name of it is “Purpose of controls” or something similar, we are going to have several SCs that contribute to the goal of personalisation, I don’t think it is a good idea to call this specific SC something as general as personalisation.


David wrote:
> I think the idea was to roll off the "instructions" type of info onto 3.3.5 Help or 3.3.2 Labels or Instructions. And just ensure the following keywords were part of the ACCNAME, ACCDESCRIPTION ROLE or another programmatic means.
Agreed, the new wording on the AA SC is focused on conventional controls having their name available. I thought the calculation from a UA point of view would be as per accessible name [1], but using a specific attribute for the purpose would over-ride it.

Cheers,

-Alastair

1] Is this the base place to reference accname?
https://www.w3.org/TR/accname-aam-1.1/#terminology It could really do with a heading after “Terminology” but before the actual calculation, I skimmed past it several times.


From: "lisa.seeman"

Hi David.

The purpose needs to be clear. that is why Jason and I will go though the list of terms and give each a clear scope of when it should be used.

FYI the current wording is:

In content implemented using markup languages, the conventional name of conventional user interface components can be programmatically determined.


(AA)

All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>



---- On Mon, 24 Jul 2017 04:28:34 +0300 David MacDonald<david100@sympatico.ca<mailto:david100@sympatico.ca>> wrote ----

Purpose of controls: In content implemented using mark-up languages, conventional user interface components can be programmatically determined.

​It's still a bit unclear...

Does "undo" need more than that, such as "undo the submission"​

Do we just want to ensure the name or another describer has the keywords in the list of 75, or is more needed. In other words. Are we trying to ensure common controls use their common names, or are we tying to ensure that the "purpose" is clear with instructions and more.

​I think the idea was to roll off the "instructions" type of info onto 3.3.5 Help or 3.3.2 Labels or Instructions. And just ensure the following keywords were part of the ACCNAME, ACCDESCRIPTION ROLE or another programmatic means.

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,



Cheers,
David MacDonald



CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

http://www.can-adapt.com/




  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Sun, Jul 23, 2017 at 2:21 PM, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:
Another thing I might add to this good list is the default button.  Sometimes it’s not clear what the default button is in a form.  Often the default button will be triggered by pressing enter – but knowing the default button could also be helpful for people who want to accept the default choice because they are not sure. This might go beyond buttons to other choices as well.

Jonathan


From: John Foliot [mailto:john.foliot@deque.com<mailto:john.foliot@deque.com>]
Sent: Friday, July 21, 2017 2:19 PM
To: lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
Cc: W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Alastair, Jan, Jason , myself and John have an updated version of

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 <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>> wrote:
Hi Folks

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

At AA

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


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


also
Upgrade and change 3.3.5 to AA -  Context-sensitive hel<https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-context-help.html#context-sensitivehelpdef>p is available for non-conventional controls  (this would included having a explanation)





All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>


--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion