- From: MURATA <eb2mmrt@gmail.com>
- Date: Wed, 9 Oct 2024 22:21:36 +0900
- To: Philipp Christoph Tautz <philipptautz@googlemail.com>
- Cc: Kevin White <kevin@w3.org>, Jan McSorley <mcsorleyjan@gmail.com>, public-global-inclusion@w3.org, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
- Message-ID: <CALvn5EAdQ2_SzVAgRR2UvpkjghOmAspns-bC9qMpakzWHCmaZg@mail.gmail.com>
Here is what HL7 does. https://www.hl7.org/fhir/datatypes.html#humanname Regards, Makoto 2024年10月9日(水) 21:02 Philipp Christoph Tautz <philipptautz@googlemail.com>: > Hi Kevin, > > Those are all good points, especially considering "Name 1” to be the first > name. I got to that because here in Japan we often have several address > fields, while in Germany where I am originally from we have “Street”, > “City”, etc. > What “Name 1”, “Name 2” etc. would allow for is some more flexibility. > > If this was formalised I would suggest to prefer “Name” and allow for > “Name 1”, “Name 2” if there is an absolute need to have more then one > field. In the end these rules need to follow what the real world gives and > while I have mostly to always suggested one name field, I have often heard > from engineers, product managers and security practitioners that these must > be 2 fields, they cannot be only one, this would be insecure, blah. > > I doubt there is a perfect solution, but if this would be a rule, I guess > pushing for 1 field and allowing for several neutrally named would the most > practical approach. > > Recommending also “What name would you prefer we call you?” would be great > addition thought! > > Best, > > Philipp > > On Oct 9, 2024, at 17:16, Kevin White <kevin@w3.org> wrote: > > This has been something that has been a vexing quirk of mine for a good > while. GDS design pattern for names > <https://design-system.service.gov.uk/patterns/names/> changed to > promoting only having one field. However, they do note that “a single name > field can accommodate the broadest range of name types, but means you > cannot reliably extract parts of a name”. Even with this change many public > sector services I dealt with in previous roles persisted in requiring first > name and surname and could not defend that position when challenged. > > I think ’name 1’ and ’name 2’ would simply cause the problem to persist > since it is likely that people would conclude that ’name 1’ was first name > and ’name 2’ surname. > > ‘Name' does the job up to the point where there is a desire or need to > extract parts of the name. One example I can think is where the service > provider is seeking to create a more informal connection. In such a case, I > would probably advocate for a question like “What name would you prefer we > call you?” > > Thanks > > Kevin > > On 9 Oct 2024, at 08:12, Philipp Christoph Tautz < > philipptautz@googlemail.com> wrote: > > Agree, definitely a good thing to point out. I can foresee issues where > security practitioners will say they need both, but as the post points out, > it is better to give options. > Since fields like Address 1 and Address 2 are already common, I would > suggest to go with “name 1” and “name 2”. Whereas only one field should > ever be required. Some people may only have 1 name. > > Thank you, > > Philipp > > On Sep 17, 2024, at 22:51, Jan McSorley <mcsorleyjan@gmail.com> wrote: > > Hi everyone, > > This came across my LinkedIn feed and I thought it would be something we > should point out in feedback to AG. Having the standard first name and last > name fields on forms does not work for everyone. > > > https://www.linkedin.com/posts/fibrhi_inclusivedesign-uxdesign-accessibility-ugcPost-7241473507136528390-yybm?utm_source=share&utm_medium=member_ios > > *Jan McSorley* > *Accessibility Consultant* > *512-731-7957 (mobile)* > linkedin.com/in/janmcsorley <https://www.linkedin.com/in/janmcsorley> > > *We put a man on the moon in the 1960's. Surely we can make information > technology fully accessible to people with disabilities. It can be done. It > must be done. It will be done!* > > > > > -- -- 慶應義塾大学政策・メディア研究科特任教授 村田 真
Received on Wednesday, 9 October 2024 13:22:20 UTC