When I first used the site, I often wasn't sure where I was within it

[jfhector]

A lot of the time during my first 40 minutes, I wasn't sure where I was within the site. And still struggle to always know where I am / what context I'm in / what it's about when I'm looking at a data table.

Here's an example of what's been going on for me, as I used the site for the first time in 6-9 months.

1. There's an overview page with lots of aria and HTML attribute listed, with a topline support table for each
2. If I click on one of the attributes, I'm taken to a page with support detail for that attribute.
   Let's say I'm on the page for aria-disabled attribute (aria) for example.
3. I see a table of expectations. Each row header is an expectation about that aria attribute.

So far, so good. I understand how this works.

4. I click on one of these expectations, imagining that I'll be be taken to a different page detailing that expectation. But instead, the page's scroll position moves. I scroll up again to see that I'm still on the same page, but I can't quite say what section of the page I am now, compared to where I was before. I'm just thinking "I'm lower down the page".

   Initially I have no idea what the relationship is between where I come from and where I am now.
   Then I realise that the heading of the grey box I'm looking at has the same title as the link I clicked on, and that I'm looking at more detailed expectations? Oh, actually these are tests.

5. I'm confused because I don't immediately see how the test (named in the row header) related to the expectation I clicked on. I scroll back to the top of the page to see the page title so I know where I am again.

6. I click on a link for one of the tests. I get navigate to a different page. I have no idea where I am. I scroll to the top of that page to see that I am on the page with test results. I realise that all results related to that test are on this page.

7. I try to find my way down again to what I was looking at. I'm not managing.

After 40min or so on the site I understand it better but I'm still confused about where I am often. For example, when I raised the previous issue, I struggled to know and name what page I was on. #96

[mfairchild365]

@jfhector this a great feedback. thank you! I'm struggling to come up with a good solution. Do you happen to have any ideas?

[mfairchild365]

Thinking about this some more...

currently, this user story describes what is happening

user story 1:
AS someone who is browsing a11ysupport.io
WHEN I am browsing the support information for a given feature
AND I click a test link within a support summary table for a given expectation
I WANT to be taken directly to details about that expectation on the test page
SO THAT I don't have to scroll down to find support details about the expectation that I was looking at

A possible change:

user story 2:
AS someone who is browsing a11ysupport.io
WHEN I am browsing the support information for a given feature
AND I click a test link within a support summary table for a given expectation
I WANT to be taken to the top of that test page
SO THAT I know where I am in the system
AND I can easily browse all details about that test

I wonder if it is possible to accomplish both user stories, as I could see both being useful. What do you think @jfhector ? There are separate links to the tests on feature pages, but they are not within the support tables. I wonder if it is possible to link both from within the support tables?

[mfairchild365]

@jfhector - I changed things up a bit. Let me know if it is more understandable now.

For expectation support summary tables:

• The row header links to the test (you are taken to the top of the test page)
• Support values within cells link to the row for the expectation/at/browser within the test

Does this at least partially address this issue?

[jfhector]

Hello Michael,

Thanks for looking into this so quickly. It's amazing to see changes being implemented and tested so fast!

User story 1 vs user story 2

With regards to the test links (like "HTML button[type="button" aria-disabled="true"]") not directing users to the top of the test page, this is definitely less dis-orientating. As you say though, it does require more scrolling / finding of the detailed of that expectation on the page.

I find it quite interesting how now the support values are links. I feel that I like this. (Of course currently these links break SC 2.4.4 but this could be fixed). I feel that this could be part of the solution. But it's hard for me to tell because I'm already aware of how the site works, so might lightweight usability testing on someone who is new to it would give a better answer.

I feel that there could be something else done. I'm not sure quite what without spending a few hours on it.

I think that part of the problem is how much information is on each of these pages.

Tangeant on how to think about design problems

Another thought, is that it might be easier to deconstruct this UX problem by listing "design considerations" or "desired outcomes", rather than user stories.

For example, two desired outcomes are that:

• Users are not disoriented when they navigate the site to understand the support of an attribute
• Users quickly understand what the support feature of a rating means (i.e. the test data behind it).

When I list desired outcomes, I'm able to capture what the design solution needs to achieve, independently of what that design solution might be. It's like I'm describing the design problem, without describing the solution. I find that very helpful.
When I express / think about design problems using User stories, I get confused. For me, User stories describe (potential) functionality. But they're not so good at describing design problems or desired outcomes.

If you're interested, you might enjoy this video of Ryan Singer (a talented designer at Basecamp) explaining this idea. The idea comes from Christopher Alexander's Phd thesis, and influenced Kent Beck and test-driven development.

Feature overview pages

I do have a few thoughts about how the feature overview pages could be easier to understand at a glance:

Let's use the aria-disabled attribute (aria) page as an example.

Styling

I didn't immediately understand what it was that I was looking at, when I was looking at the content of the section under the "Expectations" heading. First I see two tables, each under a sub heading. Then I see two grey boxes. It wasn't clear to me that the headings at the top left of these grey boxes where direct sub-headings of the "Expectations" heading. I.e. I initially thought that the grey boxes belonged to the section with the "Voice Control support by expectation" heading. It wasn't immediately, visually clear to me that the "Expectations" section had four sub-sections; I could only see the first two (namely "Screen Reader support by expectation" and "Voice Control support by expectation").

Part of the problem is that the sub-headings "Screen Reader / Voice Control support by expectation" and the sub-headings for each expectation are styled slightly differently. I.e. they're not horizontally aligned, and the headings for the expectations are in a box.

Making all the h3s within the "Expectations" section look really consistent would help.

Also, I'm imagining that it wouldn't hurt for h2s to be bigger vs h3s.

The h3s didn't jump out because table headers have a similar size and the same font-weight. I think that it'd be better for the h3s to look bigger / bolder relative to the column headers.

Removing information / clutter

I think that part of the problem is how much information is on each page, without using progressive disclosure (e.g. html details elements or similar). I'm imagining that it's partly the amount of information that is on the page that makes people like me miss things or struggle to orientate.

A few suggestions:

• When Voice Control support isn't applicable, the 'Voice Control support by expectation' table could be hidden / removed, and simply replaced by 'Not applicable'.
• I'm not entirely sure that the "Tests" section is needed, as (at least on the page I'm looking at), the pages are quite visible in the support tables).

Information architecture

What my expectations were when I first glanced at the page

Now, let's look just at the content, and order of content, in the "Expectations" section.

When I see a h2 named "Expectations", I expect to see a list of expectations directly underneath it.

I also get this expectation from the Table of Content, which says that in the "Expectations" section I will see sub-sections corresponding to the different expectations.

Reality

But in reality, when I look at the content inside the "Expectations" section, the main two visually prominent things I see are things that are not expectations. They are tables summarising screen reader support. That confused me a bit.

Potential solution

It might be worth trying an information architecture where, under a heading called "Expectations", what you see is just that: expectations.

You could have another page section / h2 heading called something like "Assistive Technologies support" (or even just "Support", or "Support overview").
This would have two h2s / sub-sections called "Screen Reader support" and "Voice Control support". (I'm not even sure that "by expectation" is needed).

So maybe your page structure could be:
h1: aria-disabled attribute
h2: On this page
h2: Support
h3: Screen Reader support
h3: Voice Control support
h2: Expectations
h3: Convey the "false" value (you might not need to repeat the word "Expectation" any more, but try it out it might help)
h3: Convey the "true" value

Caveats

• I typed these thoughts quickly
• Nothing replaces trying things out (as you're already doing) and testing with people. Don't trust a designer telling you what they think might work, without trying it out :)

[mfairchild365]

@jfhector Good catch about SC 2.4.4. However, I think the row and column headers provide enough context for it to pass. I'll cite H79. It might be good to provide an aria-label, but then I'd worry that might result in too verbose of an experience.

I'll have to think more about the other suggestions. I like them, but it is something I'll have to think about. Thank you so much for all of the feedback and ideas!

[jfhector]

I think the row and column headers provide enough context for it to pass. I'll cite H79.

You're right.

[mfairchild365]

Related: #280