– DRAFT –
Simplifying Site Navigation: A Standardized Approach for Accessible Destinations

<Abhinav> matatk: I am getting wrong passcode in zoom

<Abhinav> Can you share it over email

<kenneth> fyi if you have the w3.org/events page, the link there should have the password pre-filled

<danbri> nearby https://html.spec.whatwg.org/multipage/links.html#linkTypes https://microformats.org/wiki/existing-rel-values

<danbri> also a few bits in schema.org like https://schema.org/ContactPage

<danbri> you could say a https://schema.org/Hotel had a https://schema.org/department which was a https://schema.org/ExerciseGym (each with urls)

(meeting invite and github issue will be updated to include links to slides/demo)

Discussion

Dipika: I'm really stoked about the work you people are doing - I struggle with it myself, e.g. what is the sign in page, what is the placement of these components across different websites
… 2 things I wanted to comment/observe.
… (1) would this work also extend to sometimes in the login form, the field differs as to expectation (email, username, phone number) - is it possible for this work to extend to that?
… it's OK if you have a saved login/password, but I've come across situations where an email is expected and I keep entering my username and wonder why it isn't working
… (2) wondering if you'd consider adding About to the list of options, as it's also a pretty common page on websites

matatk: RE the second question, we will take it under consideration, it may already be in the list

Abhinav: it's already on the list

matatk: RE the first question, that's an excellent point; it's a good example of something that can confuse people

<danbri> historical browser support (rip): https://lists.w3.org/Archives/Public/www-html/2001Oct/0026.html ("Many browsers, such as iCab, Lynx and Mosaic, make use of the <link>"... 2001)

matatk: prior to this specific project, we had been looking at ways to add metadata to form fields. One of the attributes proposed would be purpose, which your use case may fit into.
… that's something I hope we will be able to come back to, and find a solution that fits that and other use cases
… really important that we solve these problems in a way that fits the community and the web platform. Sometimes we go off and get very excited about implementations, then get very valuable feedback from the community that helps simplify

danbri: I have such mixed feelings. I love this stuff, and the idea has been around in the browser community for a while, but browser support has varied, come and gone
… do you have any insight on what went wrong? Did it fail to meet user needs? Do we have any browser vendors engaged at this point?

matatk: We started from the perspective of the Adapt TF, with the user need arising from the COGA TF. Focused on need to address cognitive accessibility use cases
… whether difficulty understanding written text due to cognitive disabilities, or language barriers, etc.

https://www.w3.org/TR/coga-usable/

matatk: Genesis of adding these rel values, or purposes of form fields, etc. are ways of adding metadata to make things more understandable
… we are aware of some past approaches to make navigation more accessible, which browsers have supported, but from what you are saying, evidently not all of them, so we would value your input so we can gather more information
… in terms of feedback, we have had some feedback from people quite deeply involved in web standards; we have not put out a request for browser vendor interest on either proposal yet; want to do more experimentation first
… worth eventually reaching out to browser vendors for feedback to see what would help with adoption

danbri: It's very driven by what browser vendors are willing to implement, especially for mobile where it's more locked down
… if the browsers don't use it, it's going to join the collection of various ideas from the past 20-30 years
… also be wary of scope creep (RE e.g. nested navigation), worth thinking about schema

matatk: Funny that you mention schema, another thing we considered was linkset, but it was regarded by people we talked to who are involved with browsers as too complex to now
… we should encourage people to do this using the simplest method possible to see if people want to use it, before investing deeper in more involved or efficient methods

<Zakim> danbri, you wanted to ask about browsers

<matatk> ?

matatk: Is there anyone in the audience thinking "I would like to adopt this, but..."?

<danbri> re site-wide metadata, I would not completely reject that one just yet. There always used to be a notion of machine-readable sitemaps but it also never took off, except the rather boring sitemaps mechanism which is basically just a list of URLs.

kenneth: Any reservations about overloading so many new values into rel?

matatk: People we have reached out to so far do not seem to be concerned; as I said earlier we do want to be careful to add the minimum viable product to start out with, and could add more later. Want to avoid being too noisy for users
… being clear on that will be helpful, and being able to justify why we're asking for them to be added will be useful. We do have information from the COGA TF on this

Abhinav: We need to really see what and how many we need to add. But first we need to get something out there to experiment with and to gather feedback

JenStrickland: There seemed to be a presumption that everyone would be ready to add this into sites, and I'm not sure if that's the case? What we need is the data to prove that this is something that is needed and desired
… when this is published, it would be good to include evidence-based storytelling with the data to back it up, in order for folks I work with to take it seriously, otherwise they will be resistant

<danbri> practical q: which link from https://www.w3.org/WAI/adapt/ is best for this effort?

matatk: Thank you Jen, I did not mean to give that impression, apologies. There are 2 sides of these things, and you are focusing on the policy side; there's also the technical side of how easy is it to implement once you decide to do it
… yes we should do everything we can to justify doing it in the first place based on evidence, in addition to trying to lower the technical barrier

Abhinav: I think this is a very good point, when we are doing initial implementation, we should have data not only on how easy it is to technically implement but also how much it helps

JenStrickland: It's not only how much it helps people but the "why" - a lot of times I see people make assumptions that the web is usable, without thinking of other people's situations
… making sure that your average JS framework developer, for example, will understand why this matters, and who's being left out to date, will be critical for success

<hadleybeeman> Thank you, matatk and Abhinav !

matatk: Thanks to Kenneth for scribing. We will make all of the material available in the next few days