Audit the website for accessibility issues

[rviscomi]

Related to #286, we should do an audit of the website for accessibility issues before launch.

cc @OBTo @kleinab @rachellcostello @ljme

Outstanding issues:

• P0: (Chapter) Graphs don't have descriptive alt text nor a link to the data, so screen reader users don't have access to that information
• P1: (All pages) There are many images of cartoons that need to be decided to be either purely decorative (and get alt="") or have meaning and need alt text
• P1: (Chapter) div.big-number has insufficient contrast
• P2: (Contributors) The entire square that contains the images/links should not be in the tab order since there is no action that happens upon invoking them - this makes navigation hard and it's too verbose for screen reader users
• P2: (Home)
  White text on gray background "Table of Contents"
  Foreground:#F2F2F2
  Background:#778192
  The contrast ratio is: 3.5:1
  Expected contrast ratio: 4.5:1 or greater

Yellow text in buttons on gray background such as "Start exploring"
Foreground:#F7F779
Background:#697587
The contrast ratio is: 4.1:1
Expected contrast ratio: 4.5:1 or greater

Twitter and Github logo in the lower right corner
Foreground:#8E99A3
Background:#5C687D
The contrast ratio is: 1.9:1
Expected contrast ratio: 4.5:1 or greater

cc @HTTPArchive/developers can anyone help resolve these a11y issues?

[rviscomi]

From an email thread it sounds like @ljme may be able to start on an accessibility audit. We'll prioritize the major findings to get them resolved before launch.

[ljme]

Yes! Let's do this!

[ljme]

I've found some bugs and will take time tomorrow to write them up individually with repro steps and check them all to ensure they are cross-platform. Where is a good spot to put them?

The most pressing issues I see tonight are:

Inside the report page:
graphs don't have descriptive alt text nor a link to the data, so screen reader users don't have access to that information - most important bug
some text in the graphs has very very low contrast - I can calculate ratios tomorrow
tables don't have table headers marked up which makes them hard to navigate for screen reader users

Everywhere:
there are many images of cartoons that need to be decided to be either purely decorative (and get alt="") or have meaning and need alt text - second most important bug
The focus indication ring can be hard to see against some backgrounds I can calculate ratios tomorrow

Contributors page:
The entire square that contains the images/links should not be in the tab order since there is no action that happens upon invoking them - this makes navigation hard and it's too verbose for screen reader users - third most important bug

Homepage:
lots of text is too low of contrast, I can calculate exact ratios tomorrow - the white on gray background and yellow on gray background

And a few more.
Tested initially on Chrome OS 79.0.3945.13 (Official Build) dev (64-bit) on Caroline Chromebook with built-in magnifier, zoom, large system fonts, and ChromeVox screen reader

[rviscomi]

Thanks @ljme! I've updated the first comment to act as a todo list of issues to resolve. Feel free to edit it if you find anything else.

[ljme]

Updated the above with the contrast ratios to improve. Please let me know if there is anything else I can do right now. Thanks!

[rviscomi]

Great, thank you @ljme!

[rviscomi]

I've updated #237 to outline a process for including accessible data visualizations. To sum it up:

• every figure has a corresponding figcaption describing its contents at a high level
• every image either has alt text or a corresponding aria-labelledby element
• every iframe (interactive Sheets chart) has a corresponding aria-labelledby element
• on mobile we hide the iframe and show an identical image version of the chart

All new data visualizations are following this process and I've gone back through other chapters to ensure that they're accessible. This should solve the P0 issue.

[rviscomi]

There are many images of cartoons that need to be decided to be either purely decorative (and get alt="") or have meaning and need alt text

I think alt="" is the right way to go, but I'm open to suggestions. They add value to the visual aesthetic but not so much to the content.

[ljme]

SGTM go for it, alt="" away! Go ahead and run the lighthouse tool in Chrome DevTools if you want to be sure you caught them all.

…

On Sun, Nov 10, 2019, 3:32 AM Rick Viscomi ***@***.***> wrote: There are many images of cartoons that need to be decided to be either purely decorative (and get alt="") or have meaning and need alt text I think alt="" is the right way to go, but I'm open to suggestions. They add value to the visual aesthetic but not so much to the content. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#303?email_source=notifications&email_token=AAZ4GUSDBHPAHDF5I4VS35LQS7BK7A5CNFSM4JIH7IF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUYFPY#issuecomment-552174271>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ4GUUK6C5QGTCXABNUPH3QS7BK7ANCNFSM4JIH7IFQ> .

[tunetheweb]

@ljme I'd be interested in hearing your opinion on a conversation how I'm proposing having the details images.

We will basically have this sort of markup:

<figure>
  <a href="/static/images/2019/04_Media/fig2_total_image_bytes_per_web_page_mobile.png">
    <img src="/static/images/2019/04_Media/fig2_total_image_bytes_per_web_page_mobile.png" alt="Figure 2. Total image bytes per web page (mobile)." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" data-width="600" data-height="371" data-seamless data-frameborder="0" data-scrolling="no" data-src="https://docs.google.com/spreadsheets/d/e/2PACX-1vSViHIntdF6-bHAI0cl1HelY_X8rR4lf0P3W2Y8I5SyVMxG-ptggTHfWA0qrrU47RvuAydLE6Zex6L3/pubchart?oid=2025280105&format=interactive">
  </a>
  <div id="fig2-description" class="visually-hidden">The median web page on mobile requires 1 MB of images and 4.9 MB at the 90th percentile.</div>
  <figcaption id="fig2-caption">Figure 2. Total image bytes per web page (mobile).</figcaption>
</figure>

So we have a figure, containing a linked image and with a figcaption which is displayed on screen. That figure will also, on occasion, have a Google Sheets iframe to a nicer graphic (in which case the image will be hidden), so this will become like this:

<figure id="fig-2">
  <iframe title="Figure 2. Total image bytes per web page (mobile)." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" height="371" seamless="" frameborder="0" scrolling="no" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vSViHIntdF6-bHAI0cl1HelY_X8rR4lf0P3W2Y8I5SyVMxG-ptggTHfWA0qrrU47RvuAydLE6Zex6L3/pubchart?oid=2025280105&amp;format=interactive" loading="lazy"></iframe>
  <a href="/static/images/2019/04_Media/fig2.png" class="fig-mobile">
    <img src="/static/images/2019/04_Media/fig2_total_image_bytes_per_web_page_mobile.png" alt="Figure 2. Total image bytes per web page (mobile)." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" data-width="600" data-height="371" data-seamless data-frameborder="0" data-scrolling="no" data-src="https://docs.google.com/spreadsheets/d/e/2PACX-1vSViHIntdF6-bHAI0cl1HelY_X8rR4lf0P3W2Y8I5SyVMxG-ptggTHfWA0qrrU47RvuAydLE6Zex6L3/pubchart?oid=2025280105&format=interactive">
  </a>
  <div id="fig2-description" class="visually-hidden">The median webpage on mobile requires 1MB of images and 4.9MB at the 90th percentile.</div>
  <figcaption id="fig2-caption">Figure 2. Total Image Bytes Per Web Page (Mobile)</figcaption>
</figure>

Either the iframe or the linked image will be shown in this case but not both.

I've come up with this approach after some reading but could do with some a11y expertise to validate some assumptions, namely:

• Do you see any problem with showing an iframe and an img with the same a11y labels as long as one is hidden at all times? I presume screen-readers will recognise the display:none and ignore the hidden one?
• Do we need an iframe title when we have an aria-labelledby? Firefox accessibility tester was complaining about it so added it. Think it's probably redundant, but at same time no harm having it for none-assistive technologies.
• Is there any harm in having an alt and an aria-labelledby on an img tag? My understanding is that the alt will be ignored, so it's redundant, but at same time SEO like alts so if it doesn't cause a problem I'd like to have both. And in fact the only reason we even bother with an aria-labelledby instead of just the alter is covered in the next point!
• We have used aria-labelledby because we do have the label for the iframe/img on screen. We're hoping by using the aria-labelledby tag it will prevent the same text being read out twice. Is this the right way of going about it?
• Some of the graphs are quite detailed, and I feel more descriptive than should be in an alt/title/label so have added an aria-describedby attribute as well. Is that the right way of going about it? I presume that will be used in addition to, and not in replacement of, the aria-labelledby attribute?
• Do screen readers typically use aria-describedby? Or are we taking on extra work that won't even be used?
• The div pointed to by aria-describedby is changed to 1px * 1px by CSS (class="visually-hidden"), so it's effectively hidden, but because it's not actually hidden we hope screen readers will still see it. Is that the right way of doing this?
• Can both iframe and img have aria-labelledby and aria-describedby attributes are are these restricted to other elements?

Thanks in advance for any insights you can give here as we want to be as accessible as possible!

[ljme]

Hi bazzadp@ I am slow to respond this week, I'll get you a response as soon as I can, thanks!

[ljme]

Hi bazzadp@

Please take a look at the Accessibility page for an example of the graphs working as expected in terms of descriptions being provided for screen reader users. For example, if you take a look at the HTML for Figure 2, you'll see that this is the description I wrote that is referenced by aria-describedby:
Vertical measuring percentage data, ranging from 0 to 80 in increments of 20, vs. the device type, grouped into desktop and mobile. Desktop enabled: 75.46%; Desktop disabled 24.54%; Mobile enabled: 67.79%; Mobile disabled: 32.21%.

I'm concerned that the heart of the matter is being lost here. The most important thing is that the data that is being represented by the graph is also articulated to screen reader users. I think most of the work is in getting the descriptions written themselves or preparing links to the relevant data. Please see the end of this paper from researcher Valarie Morash for a great template on writing descriptions for the graphs.

I hope that helps!

Thanks!

[ljme]

I also just wanted to add that I hope that answer was helpful, please let me know if you have more questions or concerns!

[tunetheweb]

Hi @ljme , thanks for responding But I’m not sure you answered the question I was asking.

You seem to have looked at the description in the example. I agree it’s a little light in this example and does convey the full detail that is shown on the graph so this particular example should probably be expanded upon. I look into that separately and try to review all the figures again.

However, I was less asking about the text in the specific example and more on the approach. In this example I converted the existing markup (which I admit is a little light!) to a new structure as previously there was no ‘titleoraltattributes and onlyaria-labelledbywas used and now I use that as well asaria-describedby`.

So let’s use the example you give from from the accessibility chapter instead, as that is indeed a better example. This is what is in the markdown file, and is copied to the HTML file:

<figure>
  <a href="/static/images/2019/09_Accessibility/fig2.png">
    <img src="/static/images/2019/09_Accessibility/fig2.png" alt="Figure 2. Percentage of sites that disable zooming and scaling vs device type." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" data-width="600" data-height="371" data-seamless data-frameborder="0" data-scrolling="no" data-src="https://docs.google.com/spreadsheets/d/e/2PACX-1vSG3DTnx7j-YT1hnQpQYjDRD-rCSF1dXbgva-iJQZKdCKIt34ojGMDRhx74fF93CpPg7oGW_C68fWGT/pubchart?oid=2053904956&amp;format=interactive">
  </a>
  <div id="fig2-description" class="visually-hidden">Vertical measuring percentage data, ranging from 0 to 80 in increments of 20, vs. the device type, grouped into desktop and mobile. Desktop enabled: 75.46%; Desktop disabled 24.54%; Mobile enabled: 67.79%; Mobile disabled: 32.21%.</div>
  <figcaption id="fig2-caption">Figure 2. Percentage of sites that disable zooming and scaling vs device type.</figcaption>
</figure>

This would be expanded after the JavaScript runs to add the iframe where that is supported, so into this:

<figure>
      <iframe title="Figure 2. Percentage of sites that disable zooming and scaling vs device type." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" height="371" seamless frameborder="0" scrolling="no" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vSG3DTnx7j-YT1hnQpQYjDRD-rCSF1dXbgva-iJQZKdCKIt34ojGMDRhx74fF93CpPg7oGW_C68fWGT/pubchart?oid=2053904956&amp;format=interactive"></iframe>
  <a href="/static/images/2019/09_Accessibility/fig2.png" class="fig-mobile">
    <img src="/static/images/2019/09_Accessibility/fig2.png" alt="Figure 2. Percentage of sites that disable zooming and scaling vs device type." aria-labelledby="fig2-caption" aria-describedby="fig2-description" width="600" data-width="600" data-height="371" data-seamless data-frameborder="0" data-scrolling="no" data-src="https://docs.google.com/spreadsheets/d/e/2PACX-1vSG3DTnx7j-YT1hnQpQYjDRD-rCSF1dXbgva-iJQZKdCKIt34ojGMDRhx74fF93CpPg7oGW_C68fWGT/pubchart?oid=2053904956&amp;format=interactive">
  </a>
  <div id="fig2-description" class="visually-hidden">Vertical measuring percentage data, ranging from 0 to 80 in increments of 20, vs. the device type, grouped into desktop and mobile. Desktop enabled: 75.46%; Desktop disabled 24.54%; Mobile enabled: 67.79%; Mobile disabled: 32.21%.</div>
  <figcaption id="fig2-caption">Figure 2. Percentage of sites that disable zooming and scaling vs device type.</figcaption>
</figure>

Again only one of the iframe or the img will be shown and not both depending on the capabilities of the device. The other will be hidden with CSS.

So in this example we have a much better description, but my questions are the same as listed in #303 (comment) as you the way this has been implemented in regards to title, alt, aria-labelledby, and aria-describedby.

For example, Rick was concerned that we were being overly repetitive with effectively having the same values in the alt, title and aria-labelledby attributes for example - but I specifically choose those the way I did to try to avoid repetition as I’m hoping the aria-labelledby attribute should be used in preference to the alt and title attributes so we’re not repeating that there and in the figcaption so screen readers won’t read this sane text out twice.

So do you understand what I am asking now?

[ljme]

I need to pass on responding to this thread at this time due to other commitments.

@rviscomi Can you connect @bazzadp with another engineer who can answer the specific questions outlined in the comments above? Thanks so much!

[kleinab]

Hi @bazzadp, it might be helpful to know that there is order of operations in ARIA. So for example, if you want to name an element, the name will be resolved in the following order:
aria-labelledby, aria-label, alt, attribute, inner text, title, placeholder,
So aria-labelledby takes precedence over all of the other ways to name an element. In other words, if you had a different name for each of the values above, the name you put for aria-lablledby would win.

If you want to describe an element, the description will be resolved in the following order:
aria-describedby, title, placeholder
So aria-describedby takes precedence over title and placeholder in this case.

Does this answer your question?

[tunetheweb]

I think so thanks for confirming. So it’s fine to have the alt tag (for SEO) and duplicate the value in labelled-by (for accessibility so it doesn’t repeat the figcaption).

So I think we’re good except the color contrasts now.

[tunetheweb]

In regards to these:

P2: (Home)
White text on gray background "Table of Contents"
Foreground:#F2F2F2
Background:#778192
The contrast ratio is: 3.5:1
Expected contrast ratio: 4.5:1 or greater
Yellow text in buttons on gray background such as "Start exploring"
Foreground:#F7F779
Background:#697587
The contrast ratio is: 4.1:1
Expected contrast ratio: 4.5:1 or greater

Twitter and Github logo in the lower right corner
Foreground:#8E99A3
Background:#5C687D
The contrast ratio is: 1.9:1
Expected contrast ratio: 4.5:1 or greater

I'm not an expert but I'm not sure we do need to do anything here. The WCAG standard states the following according to MDN:

Type of content	Minimum ratio (AA rating)	Enhanced ratio (AAA rating)
Body text	4.5 : 1	7 : 1
Large-scale text (120-150% larger than body text)	3 : 1	4.5 : 1
Active user interface components and graphical objects such as icons and graphs	3 : 1	Not defined

(Btw the Firefox Accessibility check in their dev tools is awesome for checking out accessibility issues!)

So the ones highlighted (apart from the last one) are not body text and are all well within the 3 : 1 range. The Twitter and Github logos are admittedly failing this but really are secondary and are much more obvious when hovered over.

So I vote to close this issue as complete. Thoughts?

[rviscomi]

Thanks @ljme @kleinab and @bazzadp for looking into these issues. I agree this issue has been appropriately addressed and can be closed. If there are any specific a11y problems that come up we can address them in new issues.