Page MenuHomePhabricator

Optimize accessibility based on findings from external report
Closed, ResolvedPublic

Assigned To
None
Authored By
scblr
Jun 24 2019, 2:12 PM
Referenced Files
F29800168: 9779816_orig.jpg
Jul 18 2019, 9:18 AM
F29630164: image.png
Jun 24 2019, 2:12 PM
F29630172: image.png
Jun 24 2019, 2:12 PM
F29630162: image.png
Jun 24 2019, 2:12 PM
F29630176: image.png
Jun 24 2019, 2:12 PM
F29630146: image.png
Jun 24 2019, 2:12 PM
F29630182: image.png
Jun 24 2019, 2:12 PM

Description

Issues from John Lilly’s accessibility report:


Explore feed

  • 01) There is a button at the top that is just labeled as “1”. I’m not quite sure of the purpose of this button. Is the tab button properly labelled?

image.png (152×1 px, 40 KB)

  • 02) Label of the navigation item button (hamburger icon) is not labelled
  • 03) Label the voice input button icon properly. I suggest “Voice input search”

image.png (192×1 px, 33 KB)

  • 04) In the customize your Explore feed card, the “Got it” and ”Customize” buttons are not announced as buttons.

image.png (534×622 px, 197 KB)

  • 05) The bottom tab bar can never be reached by using the swipe gestures since the page scrolls infinitely. You can disable the infinite scrolling and add a “load/show more” button to allow users to load more items. You can also detect if the user is using accessibility features, but this may interfere with keyboard only users.
  • 06) Actionable elements must be announced as buttons. Currently, elements that users can click such as the controls that open articles are not announced as buttons.
  • 07) The pagination is not focusable at the bottom of the intro.
  • 08) When the user moves to the next page in the tutorial, the focus remains on the next button. Focus should be moved to the new content shown on the page.

Article page

  • 09) The Edit link is not labeled.

image.png (154×1 px, 64 KB)

  • 10) Some images in articles are not labeled.

image.png (216×1 px, 143 KB)

  • 11) After clicking the Quick Facts button, focus is placed at the top of the page.

Hybrid Device with Keyboard

  • 12) When using the keyboard to navigate, the focus cannot be moved back to the top bar with the hamburger menu and notifications button.

Color Contrast

  • 13) When using the Black theme, the color contrast between links and the background is 3.2:1. It should be at least 4.5:1. The was the only color contrast issue observed with the theme settings. Can we use colorAccent (color_group_3) for the links in dark and black mode?

image.png (678×864 px, 185 KB)


Touch targets

  • 14) The 3 dots menu button has a height of 40dp. Please increase to 48dp.
  • 15) The superscript link on articles is 13dp x 14dp. Please increase to 48dp.
  • 16) The edit link within articles is 25dp x 26dp. Please increase to 48dp.
  • 17) On the Explore page, the navigation menu has a width of 36dp. Please increase to 48dp.

Event Timeline

Charlotte renamed this task from Fix issues from external accessibility report to [Spike] Investigate issues from external accessibility report.Jun 24 2019, 4:24 PM
Charlotte lowered the priority of this task from High to Medium.
Charlotte updated the task description. (Show Details)
Charlotte lowered the priority of this task from Medium to Low.Jul 8 2019, 10:29 PM

Hi @schoenbaechler

Most of the changes can be done, and I have some comments/questions on the following items:

  1. Some images in articles are not labeled.

It might be done in the wikimedia-page-library side by adding alt tag (haven't tested it yet.)

  1. The 3 dots menu button has a height of 40dp. Please increase to 48dp.

Does it mean to enlarge the clickable area? and the actual "3 dots" remains the same size?

  1. The superscript link on articles is 13dp x 14dp. Please increase to 48dp.

Not sure if it can be done now. It is a HTML <sup> tag.

Thanks @cooltey, looking forward to these improvements. I’m definitely advocating to treat this as more than just “Low“ priority as accessibility is a core requirement for our products:

9779816_orig.jpg (463×924 px, 45 KB)

Image source: https://slidebird.com/user-experience-die-beduerfnispyramide-des-nutzers/


In regards to your points:

  1. Some images in articles are not labeled.

It might be done in the wikimedia-page-library side by adding alt tag (haven't tested it yet.)

I see, appreciate your efforts/investigations!

  1. The 3 dots menu button has a height of 40dp. Please increase to 48dp.

Does it mean to enlarge the clickable area? and the actual "3 dots" remains the same size?

Yes, you got it!

  1. The superscript link on articles is 13dp x 14dp. Please increase to 48dp.

Not sure if it can be done now. It is a HTML <sup> tag.

Do you know who could make it happen if it’s not in our hands?


Thanks!

Hi @schoenbaechler

Do you know who could make it happen if it’s not in our hands?

Maybe @bearND have some idea about enlarging the citation (<sup>) link clickable area.

However, I think it might be fine since the references can also be found in the "References" section on the bottom of the article.

Do we want to increase the click target of all reference links for everybody or should it be a client specific setting?

If the former then I think the link click target issue is best handled upstream by MinervaNeue. If that's not possible we could add a CSS rule to the pagelib. @Volker_E might want to chime in as well.

While there are CSS hacks available to increase the clickable area around a link I think it's problematic when there are multiple of such links nearby, like [4][5][6]. (In this case the last link usually wins.)

If we don't want this to be done for everybody and we only need a boolean flag or a small set of values then a CSS rule like

pagelib_ref_links_large .content .mw-ref, sub, sup {
  font-size: 1.5em;
}

could be triggered by the class pagelib_ref_links_large added to the root <html> element. This is similar to what we do for other CSS settings in the pagelib.

Another approach could be to add a style element to the DOM with the appropriate rule and sizing.

@bearND has already shared on major issue with multiple references side-by-side. We've additionally run into issues with line-height
CSS having negative consequences on line formatting (expanding distance) in the past. I'm not aware of an easy way to extend clickable area of links (mixing in display: inline-block with rendering consequences), that is free of side effects.
For sake of simplicity, I'd ignore the click target in this specific case with superlined text as they are only shortcuts to information that is anyways accessible at end of article.

Some images in articles are not labeled.

A collaboratively edited encyclopedia where most people are not trained in accessibility will always introduce some level of inaccessibility. if you want to fix this, focus on editing tools or possibly 'linting', not on 'filling the attribute with something'.

@cooltey, thought I’ll recap in regards to:

  1. The superscript link on articles is 13dp x 14dp. Please increase to 48dp.

Not sure if it can be done now. It is a HTML <sup> tag.

Do you know who could make it happen if it’s not in our hands?

According to @Volker_E, let’s ignore it for now:

For sake of simplicity, I'd ignore the click target in this specific case with superlined text as they are only shortcuts to information that is anyways accessible at end of article.

Also, thanks to @bearND & @TheDJ for your advice and insights! 👊

@schoenbaechler Sounds great. The Investigations are finished and now it's ready to work on it.

Maybe we can keep this ticket and update the ticket title, or you can create another ticket to actually implement it. It is up to you :).

scblr renamed this task from [Spike] Investigate issues from external accessibility report to Optimize accessibility based on findings from external report.Jul 25 2019, 11:29 AM

Thanks @cooltey, changed the task’s title. To re-emphasize:

I’m (...) advocating to treat this as more than just “Low“ priority as accessibility is a core requirement for our products.

Under these circumstances, let’s get ready to rumble?! {CC @Charlotte)

Yes, I will put in ready for dev.

Move to Blocked/Waiting since we're going to finish the mobile-html tasks first.

Note:

Feedback about the article page, such as "link color", "image label", "icon size"...etc, require update from wikimedia-page-library.

(10) Some images in articles are not labeled.
(11) After clicking the Quick Facts button, focus is placed at the top of the page.
(13) When using the Black theme, the color contrast between links and the background is 3.2:1. It should be at least 4.5:1. The was the only color contrast issue observed with the theme settings. Can we use colorAccent (color_group_3) for the links in dark and black mode?
(15) The superscript link on articles is 13dp x 14dp. Please increase to 48dp.
(16) The edit link within articles is 25dp x 26dp. Please increase to 48dp.

For now, we are blocked by the progress of implementing the mobile-html

Requires Page Content Service to complete the changes:

09) The Edit link is not labeled.

It says "Index link" now, and it should be changed to "Edit section" with the current section title.

(10) Some images in articles are not labeled.

We can ignore this.

(11) After clicking the Quick Facts button, focus is placed at the top of the page.

No longer reproducible.

(13) When using the Black theme, the color contrast between links and the background is 3.2:1. It should be at least 4.5:1. The was the only color contrast issue observed with the theme settings. Can we use colorAccent (color_group_3) for the links in dark and black mode?
(15) The superscript link on articles is 13dp x 14dp. Please increase to 48dp.
(16) The edit link within articles is 25dp x 26dp. Please increase to 48dp.

These should be done in the PCS.

LGoto added a subscriber: cooltey.

@cooltey - Can you please go back through the recommendations now that mobile-html is ready, and see what (if anything) still needs to be done? Add any additional mobile-html side fixes needed to the ticket @JoeWalsh will link below.

Here is the ticket with the article a11y improvements requested for iOS T249355

Hi @Charlotte,

Here is the ticket I have already created that addresses the remaining changes need to be done: https://phabricator.wikimedia.org/T242175, and it looks like the ticket is still sitting on the Backlog.

Thanks - the rest of the stuff is in the PI backlog so I'm closing this ticket.