Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spell out first WCAG acronym in Writing Tips and maybe remove link... #209

Closed
James-Green opened this issue Sep 3, 2015 · 7 comments
Closed

Comments

@James-Green
Copy link

On the writing tips page, the first mention of WCAG is a link to the what-is-wcag aside.

I think we should spell out the acronym since it's the first mention on the page (with styles on). Now, with styles off, that aside is actually before the H1, but will be missed by a screenreader user that clicks the skip to content link as that goes to the H1. So, for most people it's really the first instance.

Clicking the link moves focus to the aside which seems problematic to me for a couple reasons:

  1. visually, it scrolls the page down just a couple inches to bring the aside (over on the right side of the screen) at the top of the browser. For a visual user, this was confusing.
  2. for a screenreader user, it moves the focus up to the aside, something the user may have already heard (if they tabbed through the nav) or hadn't heard but would not likely expect to be above the H1.

Not a huge deal, but I wanted to get people's thoughts on linking instead to an external page about WCAG, or removing the link altogether.
screen shot 2015-09-03 at 2 10 16 pm

@iadawn
Copy link

iadawn commented Sep 7, 2015

The aim of the side panel was to briefly introduce what WCAG and SC are without directing readers away to a more involved page. There is a suggestion to remove 'SC' as it is not that necessary, but that still leaves WCAG to be introduced a little bit.

The structure of the page means that the About WCAG panel does come before the main H1 on the page. It may be quite challenging to change this.

Would removing the WCAG link in the intro and expand the acronym alleviate your concerns?

@James-Green
Copy link
Author

Got it. Yes, removing the WCAG link in the intro and expanding the acronym would work for me.

@nitedog
Copy link

nitedog commented Sep 9, 2015

I agree that the acronym "WCAG" in the intro paragraph is the first occurrence for many. This is why it is linked to the aside, for expansion and explanation. The aside is before the h1 so that people return to the h1, if they are not experience screen reader users. This seems to work fine in most cases.

Expanding the acronym and removing the link has many downsides, and I do not recommend it:

  1. It makes the intro paragraph much longer and duller (not a very exciting document name)
  2. It becomes unnecessarily repetitive for those who know WCAG already
  3. It does not provide the explanation that we provide in the side bar.

@iadawn
Copy link

iadawn commented Sep 10, 2015

The order of the side panels isn't necessarily ideal but it matches the broader WAI site.

Closing this issue, following on from @nitedog comments. @James-Green, if you still feel that some action is required, please do reopen.

@iadawn iadawn closed this as completed Sep 10, 2015
@James-Green
Copy link
Author

Hi @iadawn, I would like to reopen this issue - I feel very strongly that this interaction is problematic as designed. We all agree that the first exposure of an acronym needs explanation, but my concern is that we are not delivering that explanation is a usable way.

Since I don’t primarily use a screenreader, I don’t feel I have enough context to take a stand on whether the H2 being above the H1 would really pose a problem for screenreader users, but I feel that a link moving you up on the page would be unexpected (and even small usability issues add up) and I would argue that we should (and would be expected to) properly nest headings and start with an H1 anyway.

Regarding the downsides @nitedog mentioned, here are my thoughts:
1. To me, it’s just 4 words that aren’t dull at all if a user doesn’t know what WCAG means. Below all my comments, I’ve attached screenshots of the current paragraph plus a version with WCAG spelled out - they are barely different.
2. If a user does know what WCAG means, they're already used to this repetition and would likely accept it as normal. Most sites that mention WCAG spell it out the first time. And if they're very familiar with WCAG I think they'd be expecting us to spell it out to meet 3.1.4.
3. I’m glad we have the side bar freely available to users to notice and read but if we are going to link people to the anchor I think we need to do it differently:

My note above may not have been clear, but when you click on the link (as a sighted user), the page scrolls down to the About WCAG heading. The blue line in my screenshot represents the new top of the browser window.
screen shot 2015-09-10 at 2 40 54 pm
I was very confused by that because I didn’t understand that focus was at the aside on the right. I couldn’t understand why it scrolled down to the middle of a list… also, I actually expected the link to either take me to the WCAG documentation or a separate page about WCAG.

To be sure it wasn’t just me, I ran 30-second usability tests on 4 people not familiar with the page and ranging from barely to fairly familiar with accessibility and WCAG. I asked each to tell me what they expected the WCAG link to do and then to click on it and “think out loud” after clicking the link. All 4 had the exact same response: They expected it to link to the WCAG documentation and when it scrolled the page down, they were all surprised - none of them realized focus had moved to the About WCAG H2, they thought something went wrong.
wcag_spelled_out_sample

@iadawn
Copy link

iadawn commented Sep 11, 2015

Thanks for the improptu usability testing, much appreciated.

The link to the <aside> was introduced in #181. I will flag this for @slhenry to comment.

@nitedog, can you live with including the expanded acronym?

@iadawn iadawn reopened this Sep 11, 2015
@iadawn
Copy link

iadawn commented Sep 17, 2015

Addressed in d672456

@iadawn iadawn closed this as completed Sep 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants