Matthew Atkinson (he/him): So welcome everyone. Thank you. This is a presentation and a demo. And then a discussion about a problem that the Adapt Task Force has been working on for some time. And I am going to now attempt to share the slides for our presentation. Just bear with me whilst I get that up and running. Okay, the share button has moved right? So I will start sharing, and we can begin from here. So I will step through the slides. Abhinav is going to be talking in the 1st part of the presentation and then I'll give you a demo. And then after that we will have a little bit more presentation, and then hopefully, a lot of discussion.

Matthew Atkinson (he/him): Take it away, Abhinav, and I will do my best to keep up with you on the slides.

Abhinav Kumar: Whenever I tell next slide, please do that, we'll go with the previous slide. Yes, previous slide.

Abhinav Kumar: So Hello, everyone. I'm Abhinav. I work for SAP in Bangalore, and I'm super excited to be presenting about simplifying site navigations as standardized approach for accessible destinations today along with Matthew.

Abhinav Kumar: Next slide.

Abhinav Kumar: So today we will be covering the problem statement, followed by, we'll be understanding what we mean by navigation barriers. Then there will be a demo, basically from Matthew. Then we will also see the revised solution, how we achieved the demo based on the feedback which we received over the last year, then we will be covering the open questions which we still have to solve, followed by the next steps which we see from the Task Force perspective we need to do. And post that, we will open for Q&A and the interactive discussions.

Abhinav Kumar: Next slide, please. Next slide.

Abhinav Kumar: So this slide, or basically this presentation, is the latest work from the WAI-Adapt Task Force. You can find more details about the task force in this talk in the links provided in this is slide. Next slide, please.

Abhinav Kumar: So this specification was a work under progress till some time back, but based on the feedback which we received over the last year, basically the community feedback, we feel that we can reach to our goal using the existing specifications. You will see more about it in the coming slides. And during the demo.

Abhinav Kumar: Next slide.

Abhinav Kumar: So what we are proposing is basically, next, is basically a standard mechanical way, using which the websites can tell about the popular pages they offer.

Abhinav Kumar: Basically, the user agents can automatically discover these popular pages aces which the website is providing.

Abhinav Kumar: So when I talk about a destination from the perspective of these popular pages. What I mean is the pages which are common across many websites. Like the homepage, the product page, and the contact page. These kind of things, if you see, is there in the taxonomy of every website which you encounter, there will be a home page, there will be a contact page. It's though not always. But most of the times.

Abhinav Kumar: Next slide, please.

Abhinav Kumar: So why we want to make finding these popular pages easy for the end user, why the discovery should be easier.

Abhinav Kumar: There are multiple reasons for it, and one of the prominent reason is the variation in the terms. So let's take an example of a user trying to log into his account, and he can see various terms for the same thing. Login, sign in, sign on, log on. And similarly, these terms can be there in different languages, as if the website is not translated in the locale which the user is used to.

Abhinav Kumar: This creates a problem for the users to identify their common one popular places which they want to do, and this becomes even more prominent for the people with cognitive disabilities.

Abhinav Kumar: Next slide.

Abhinav Kumar: So if we see, the other reason is basically many times the websites are not very intuitive, from the look and feel perspective. If you see this particular example, the page, the footer section, has the links to the about, accessibility, and the contact page. This footer section has a low contrast, and it can be difficult for people to find it.

Abhinav Kumar: The major problem is there is no standard way via which the users can identify these popular things which they require on their daily basis.

Abhinav Kumar: Next slide.

Abhinav Kumar: So now we will be seeing how we can solve this problem. We'll be seeing the solution. As part of the solution, we also have a UI, basically a browser plugin built up, which will show how the UI for the solution can look like. With this, I hand it over to Matthew to walk us through the demo.

Matthew Atkinson (he/him): Okay, thank you, Abhinav. I'm just going to get the demo ready. And in the slides as linked from the presentation deck (which hopefully is also linked from the Github issue and the calendar invite, but if it's not, we will add those links, as soon as we can), you will find a series of screen grabs around the the possible user interface of a browser extension for exposing these well-known destinations to the user.

Matthew Atkinson (he/him): What we will do, though, is actually show you a interactive version of that user interface in the form of a browser extension that demonstrates how it might look.

Matthew Atkinson (he/him): I'm just going to share that now, and get the right tab open.

Matthew Atkinson (he/him): So here it comes. We do have a few questions around the way it looks and the way that it exposes certain things. I've just noticed. It seems like the recording has stopped. I'm not sure if that's the case?

Ken Franqueiro: I still see, pause and stop controls, so I would assume it's still on. I still see the indicator at the top.

Matthew Atkinson (he/him): Ok. They've disappeared for me. Everything's changed in terms of its position. Okay, sorry about that. Here we go. This is going to be just an example website. It's an example shopping website. It has various different parts to it. I guess one thing to ask is when those of you that can see the screen share. Do you see the browser's user interface as well as the tab content? Or do you just see the web page?

Ken Franqueiro: Tabs in the address bar out there.

Matthew Atkinson (he/him): Okay, brilliant, because we need those for the the demo. So you could navigate around this site using links. And I'll just make the text a bit bigger. Or at least I will end over to. There we go.

Matthew Atkinson (he/him): You could navigate around this website using links. So for example. You might go to the Products page. And it's just a placeholder here of a products page. This website is fairly simple. So it might be clear to you how to navigate it. But just as an example, the extension here gives us a list of the so-called well known destinations that this website supports. So we've got 5 of them here. And the interesting thing, or the most interesting thing at this point is that the login item is presented in the terms that the browser knows this user understands, which might differ from those expressed on the site. So we've got the login item in the browser extension UI. But when you follow that link, you ask it to go to that destination, it takes you to the page which this website is calling sign in".

Matthew Atkinson (he/him): And there are also some other common destinations here as well. We have the homepage. We've got the contact page here that takes you to this particular contact form, for example.

Matthew Atkinson (he/him): The user interface, there is fairly simple. There's a couple of open questions that we have around that. But just before we go into that side of it, I want to show you how this is actually working from a a technical perspective. I'll also make the text here a bit bigger if I can do that. There we go. I will resize this a bit. So it's easier to read.

Matthew Atkinson (he/him): How this is working is in the head part of each page, we have various link elements, standard link elements with rel attribute values which we are in the process of of coming to some consensus about what the minimum viable set of these should be, but they are specifically relating to these destinations. So, for example. we have accessibility-statement", will take you to the site's accessibility statement. The rel attribute value of "login", which is just the string that's been assigned to this particular function on this site. The URL is /sign-in". On others, it might be login, or it might be account or something else.

Matthew Atkinson (he/him): These rel values, of course, the individual strings, they are not going to be shown to the user as is. The purpose of them is to alert the user agent or the extension in this case as to what's available and have it present these as appropriate to this particular user. So I will now go back to the rest of the presentation so that we can complete this, and then, have some question and answer discussion. Hopefully, you can all see the slides now in full screen again. Is that the case?

Ken Franqueiro: Yep.

Matthew Atkinson (he/him): Okay, brilliant. Thank you. So our revised solution. We had an initial approach that we proposed last year, based on well-known URIs but that was found to be not able to support necessarily all the use cases that we have, and it would have required some changes to the way that existing specs work, whereas using link elements and rel attribute values does require us to register the rel attribute values, but it's a lot more compatible with existing specifications, and it should be easier for authors to adopt in the 1st instance, because they have control most likely over the HTML that gets sent out, whereas well-known URIs are perhaps harder to for them to customize. And also they are scoped to the the domain as a whole, or the subdomain as a whole, rather than this particular approach which can adapt to different site structures which we'll talk about briefly. But as you've seen, the proposal now is very simple. It's using link elements and additional rel attribute values and a UI extension.

Matthew Atkinson (he/him): And we're talking about rel attribute values like accessibility-statement, contact, home, login search, and others. Our list of what is important in terms of destinations came originally from the Cognitive Accessibility Task Force within W3C.

Matthew Atkinson (he/him): And that's one of the main groups that we've been liaising with so far as to a minimum viable product set of these destinations. We don't want them to be too specific, because we don't want like landmark regions on a page. We don't want to overwhelm the user with destinations, but we do want to make sure that we are covering the important ones.

Matthew Atkinson (he/him): Here's an example of some code in the head of the HTML document, with some examples as you've seen, and of course the the key thing as we've pointed out in the demo, is that these are the standard sort of tokens the site can map whichever URL is applicable for the site to the standard tokens. And the user agent or extension can present the token in a way that fits the user.

Matthew Atkinson (he/him): Again, they're not shown directly to users, they're used for communication between the website and the user agent.

Matthew Atkinson (he/him): We've got some open questions. One of the things that the Cognitive Accessibility Task Force asked us was to indicate to them the type, particularly in the case of a help page or a contact page, is the type of help that is available. Are we talking about getting help from a person via email or phone number? Or are we talking about an online chat, or an AI based online chat? Or is it more like reference information? So that was something that we weren't sure how to incorporate into the scheme that we've got.

Matthew Atkinson (he/him): Another question would be, how best to represent nested structure. So, for example, if you have a website which is for a hotel or the domain is for a hotel, but people have put sub-sites at different routes under that URL tree. Say, for example, there might be one for the restaurant. There might be one for the gym, and then the parent one is for the hotel as a whole. Then the restaurant's website will probably have a contact page, so will the gym. But that will be different information from the hotel's contact page. So how to present that nested structure.

Matthew Atkinson (he/him): Now, with this approach, it can be more flexible, because we're not scoping these to domains or subdomains like well-known URIs would be. But there's still a question as to how to represent that there's some subsite there. Some of this will involve user interface exploration with people, maybe best practices about how to indicate that. But that's an open question.

Matthew Atkinson (he/him): And are we missing any common destinations?" is another question. And, as I said, our initial list came from the Cognitive Accessibility Task Force.

Matthew Atkinson (he/him): So next steps. We hope to have a discussion right now with the people on the call and we would like to take some feedback, and any questions that you have. But for the task force. As I said, finding the minimum viable product scope and the rel attribute values, horizontal review and wide review from the community, seeking implementations, and then wide review from the community.

Matthew Atkinson (he/him): One of the things that that wasn't necessarily shown in the demo, but we could do, is... and this is up to the sites, and they could already do this with CSS as it exists. They could style the element that is the target or the fragment which is the target of the link when the user visits that page. So they could, for example, emphasize the area of the page which is most important for that destination. Or maybe we feel that might be something to toggle in the settings for this particular user or the extension. But that's another thing that we could do to help users avoid distractions like other content on the page.

Matthew Atkinson (he/him): As I said, we will make sure this is linked from the calendar entry and Github issue for this session. We have an explainer. We have a link to the demo extension, both of which are going to receive updates very shortly after this presentation. And there's a link also here that you'll be able to follow to the Task Force. You're very welcome to join us. And with that we can stop the presentation.