Meeting minutes
<lisa> we can hear you Jan
<lisa> next item
Lisa: Matt and Lionel providing updates today from ADAPT task force. Originated from issue paper about semantics re: assistive tech for people with communication disabilities
<lisa> next item
Lisa: COGA task updates; updating issue papers, user research, and more usable/updated Content Usable. Incorporating mental health more methodically.
Lisa: Reviewing issue papers' statuses. See links to Google Docs and Github
Lisa: Online Safety and Supported Decision Making papers may be of particular interest to ADAPT
<Jennie> +1 to Lisa's caution
Jennie: Supported Decision Making may also relate to passwords and password management, as well as how information is shared in collaborative working environments where second person may be involved. For example, consenting online
Lisa: Be careful around protecting people's rights online to avoid restricting freedoms
<lisa> links are at https://
Mat: Is COGA familiar with passkeys and does it address some of the concerns around password management?
Lisa: passkeys do not address these concerns. Concerns around enabling autonomy while also safeguarding. For example, a person experiencing a manic episode may make online decisions they would not otherwise want to. Issues may be of most interest to folks working on authentication.
Lisa: EA and Tiffany have also been adding updates re: symbols
<kirkwood> no access ^
<kirkwood> resolved
EA: Concerns around AI need to be addressed, especially for complex contexts like mapping symbols to text. See and comment on linked draft
Lionel: Two topics for discussion today: well-known destinations and symbols
<matatk> Well-known destination slides: https://
matatk: Adapt is looking at some of the use cases COGA has identified as significant - looking at subset that could possibly be solved via machine-readable metadata.
matatk: proposal presented to AC to make site navigation more accessible with well-known destinations
matatk: proposing standardized, mechanical method of presenting popular types of pages so user agents can easily identify which of these pages a site has. Examples: home page, contact page, products page
matatk: addresses issues with variation in terms (e.g., log-in v. sign-in v. log on); unfamiliar or unreadable menus/footers/page organization, etc.
matatk: There is already a spec for well-known URLs with an existing registry
matatk: from the user perspective, they would not see these URLs, but would see a list of these site destinations in the browser in the way they've personalized how to view them.
Jennie: Exciting to see how help is presented here, especially re: the visual location. Trying on different screens is important
Jennie: If you consider the needs of someone with needs for similarity in presentation - for example, someone providing IT support - if someone's personalization does not match what others trying to troubleshoot see, how would that be addressed?
matatk: not trying to change the how the site is visibly rendered - providing signposts, but there is still a risk for confusion
matatk: the site needs to note that it provides these links, so in the scenario above, the support person should be aware that a user may be using different terms. But does this impact how a user can communicate with other users
Lisa: Are the terms sufficient? For example, people may be looking for help and it leads them to a chatbot, which doesn't work for them
Jennie: the term "help" is interpreted many ways between developers and users. From tips to contact info to human help or bot help within an interface. The end users want a distinction between a bot alone or a bot that can lead to a human. Want specifications for the types of help they may receive
Jennie: "help" is also conflated with "feedback" when an end user wants to report that a site is not working properly
Lisa: And help re: content v. help re: technology
kirkwood: question about standardizing the location on the page
matatk: with this proposal, the location and the product itself are distinct, but from a user perspective, they are connected. Related to issues with distraction as well. That's not currently fleshed out
kirkwood: interested in staying in contact about location
Lisa: Is that related to the user agent?
Lionel: There's the location of where is your well-known tool as an end user, which you personalize. What John is asking about is once you arrive on that page, how do you navigate to the correct part of the page with the well-known destination
Julie: Question about "Search" - does the well-known destination need to indicate if it leads you to a chatbot?
matatk: currently existing spec just leads you to a URL. Does not provide any additional information beyond that.
matatk: Providing additional information is another level of sophistication - we may be able to build on top of the currently existing spec or to think differently about it. Adapt has another module planned about help and support in the future, where we can possibly address differentiating those different types of support in the future
<Jennie> * Rashmi has her hand up in Zoom
Julie: example of organization replacing search with chatbot meaning that this issue may need to be addressed.
Lionel: each site will decide for itself how to categorize these well-known destinations
Rashmi: Asking question about easily returning to home page, especially in situations where there might be multiple landing pages on a website
Lisa: For example, if your bank has a home page and your bank account also has a home page and you need to easily navigate to both
Lisa: It would be good if there was room to expand infrastructure across lots of different categories, not just help and support. Examples in home pages, contact methods, etc.
matatk: agree; well-known URLs are absolute, so may need to layer additional tools if these do not meet the critical use cases
matatk: the issue of subsites has come up - some methods work well with well-known URLs and others don't, so currently thinking through this.
Lionel: We would like for COGA to think through this more and give us feedback
Lisa: Maybe a next step is to look at the work around and see if it actually works for the user in these instances?