Page MenuHomePhabricator

[EPIC] Enhance accessibility of OOUI & MediaWiki UI library / LSG / MediaWiki General to screen readers and color-deficient users
Closed, ResolvedPublic

Description

Task list & timeline:

  • Triage accessibility bugs on Phabricator (Q2)
  • Finalize color palette (grays, blues, reds, greens, yellows, orange) that meets WCAG 2.0 guidelines at minimum Level AA (Q2) T109915
  • Test with color-deficient users on color palette (ongoing…)
  • Revise and improve our current methods of communications with community members and foundation employees to raise accessibility concerns

Related Objects

StatusAssignedTask
Resolved Spage
Resolved Spage
Resolved Spage
Resolvedori
OpenNone
ResolvedNone
OpenNone
ResolvedAnomie
OpenNone
OpenNone
OpenNone
Resolved Spage
OpenNone
Resolvedjeropbrenda
OpenNone
DeclinedQgil
Resolved Spage
ResolvedQgil
ResolvedQgil
ResolvedQgil
Resolved Spage
Resolved Spage
Resolved Spage
OpenNone
OpenNone
Resolved Spage
Resolved Spage
Resolved Spage
ResolvedVolker_E
DeclinedNone
DeclinedNone
ResolvedVolker_E
ResolvedVolker_E
DeclinedNone
DeclinedNone
ResolvedVolker_E
ResolvedPrtksxna
ResolvedNone
ResolvedPrtksxna
ResolvedVolker_E
InvalidVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedNone
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
DuplicateVolker_E
ResolvedNone
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedNirzar
ResolvedVolker_E
OpenNone
OpenVolker_E
ResolvedNone
ResolvedVolker_E
Resolved violetto
OpenNone
OpenNone
ResolvedVolker_E
ResolvedIsarra
ResolvedVolker_E

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 13 2015, 5:49 AM
violetto renamed this task from [Goal] Enhance accessibility of MediaWiki UI library / OOjs UI / LSG to screen readers and color-deficient users to [GOAL] Enhance accessibility of MediaWiki UI library / OOjs UI / LSG to screen readers and color-deficient users.Nov 18 2015, 1:19 AM
violetto updated the task description. (Show Details)
violetto updated the task description. (Show Details)Nov 18 2015, 6:28 AM
violetto updated the task description. (Show Details)Nov 18 2015, 6:40 AM
violetto updated the task description. (Show Details)Nov 19 2015, 1:32 AM
violetto updated the task description. (Show Details)
violetto updated the task description. (Show Details)
violetto updated the task description. (Show Details)Nov 19 2015, 1:34 AM
violetto triaged this task as High priority.Nov 19 2015, 3:16 AM
Volker_E renamed this task from [GOAL] Enhance accessibility of MediaWiki UI library / OOjs UI / LSG to screen readers and color-deficient users to [GOAL] Enhance accessibility of OOjs UI & MediaWiki UI library / LSG to screen readers and color-deficient users.Dec 5 2015, 1:13 AM
Volker_E updated the task description. (Show Details)
Volker_E updated the task description. (Show Details)Dec 5 2015, 2:17 AM
Volker_E renamed this task from [GOAL] Enhance accessibility of OOjs UI & MediaWiki UI library / LSG to screen readers and color-deficient users to [GOAL] Enhance accessibility of OOjs UI & MediaWiki UI library / LSG / MediaWiki General to screen readers and color-deficient users.Dec 5 2015, 5:40 AM
Volker_E updated the task description. (Show Details)
Volker_E updated the task description. (Show Details)Dec 5 2015, 6:15 AM
Volker_E updated the task description. (Show Details)
Rezonansowy added a subscriber: Rezonansowy.

T63801 should be present here, we need to distinguish the content from the footer of the page, which is important for screen readers.

@Rezonansowy This is not true as long as role=contentinfo is present in the markup at the contentinfo element. The new HTML5 sectioning elements are just mapped to the corresponding ARIA roles.
IE up to v11 doesn't support any of the mapping of HTML5 structural elements like for example <footer> to role=contentinfo.
As long as we use ARIA role attributes we're well-supporting older and current browsers/screen readers. That was the reason for me to remove this task from the specific UI-Standardization goal.

@Rezonansowy This is not true as long as role=contentinfo is present in the markup at the contentinfo element. The new HTML5 sectioning elements are just mapped to the corresponding ARIA roles.
IE up to v11 doesn't support any of the mapping of HTML5 structural elements like for example <footer> to role=contentinfo.
As long as we use ARIA role attributes we're well-supporting older and current browsers/screen readers. That was the reason for me to remove this task from the specific UI-Standardization goal.

But how the screen reader could detect where's the page's footer? It's important, as there are such information like: when the page was last modified or the license of the content and others. These things should be provided to the user by some way.

Volker_E added a comment.EditedDec 22 2015, 5:37 PM

@Rezonansowy I might misunderstand what you're referring to. But that's exactly what the already present role=contentinfo is for. See for example view-source:https://en.wikipedia.org/wiki/WAI-ARIA - Source of WAI-ARIA article on English Wikipedia:

<div id="footer" role="contentinfo">

@Volker_E But the content and footer are not the same. They both contain some information, but they should be distinguished in some way. Using <footer> is only idea, I know. That's why I carry T63801 on.

@Rezonansowy I still don't understand what you are referring here? What do you mean by content? A screen reader accesses the DOM in modern browsers via the accessibility tree. In Google Chrome you can see what's exposed by visiting chrome://accessibility/
It doesn't matter if you wrap the footer contents in a <footer> or a <div> element as long as the broader supported attribute role=contentinfo is available on either. There is currently no accessibility advantage on using <footer> over <div>, besides the future possibility of getting rid of the role attribute. But IE up to 11 and also older browsers need us to stay with the attribute.

@Volker_E Like I said, footer div is not the same, as div with article contents. That's why HTML5 comes with aside, article and footer tags. Every piece of website should be named properly. And that's the accessibility deal. https://dequeuniversity.com/assets/html/jquery-summit/html5/slides/landmarks.html

Volker_E added a comment.EditedDec 24 2015, 8:37 PM

@Rezonansowy For whom is it not the same? For humans (developers in love with HTML5 semantic elements, like myself) or for rendering and parsing software? The article you're linking to is pointing out the same that I've laid out in my arguments above:

Similar functionality is available using the ARIA (Accessible Rich Internet Application) attributes role="banner", role="navigation", role="main" and role="contentinfo".

So there's currently no accessibility deal connected with not using <footer> as long as role=contentinfo is present in the footer div for parsing/rendering software/assistive technology. Is your definition of accessibility probably different than mine or might I miss something out?

@Volker_E Well, OK. If the article on the page has role=main, this would be enough to achieve this goal.

Volker_E updated the task description. (Show Details)Jan 7 2016, 4:23 AM
Volker_E updated the task description. (Show Details)Jan 10 2016, 11:46 AM

Since Jan 1, we entered a new quarter (Q3) and this task was our goal for the last quarter (Q2). We still have our eyes on these unchecked tasks and they are continuously being worked on and awaiting finalization.

We'll be renaming the [GOAL] part the label to avoid confusion.

Volker_E renamed this task from [GOAL] Enhance accessibility of OOjs UI & MediaWiki UI library / LSG / MediaWiki General to screen readers and color-deficient users to [EPIC] Enhance accessibility of OOjs UI & MediaWiki UI library / LSG / MediaWiki General to screen readers and color-deficient users.Jan 21 2016, 8:32 PM
Volker_E updated the task description. (Show Details)Jul 6 2016, 1:17 PM
Jdforrester-WMF moved this task from Backlog to Reviewing on the OOUI board.Mar 10 2017, 8:28 PM
Volker_E moved this task from Reviewing to Doing on the OOUI board.Apr 3 2017, 10:30 PM
Volker_E closed this task as Resolved.Jul 17 2017, 7:14 PM
Volker_E claimed this task.

This has been established as a task combining mixed topics on different products. We've been successfully tackling the technical parts of it, testing and documentation don't need this as umbrella task any further.

Volker_E updated the task description. (Show Details)Jul 17 2017, 7:15 PM
Volker_E removed a subscriber: violetto.

This has been established as a task combining mixed topics on different products. We've been successfully tackling the technical parts of it, testing and documentation don't need this as umbrella task any further.

I had been thinking the same

@Volker_E closed this task as Resolved.

Sorry to bring this up here but https://www.mediawiki.org/wiki/Wikimedia_User_Interface has a "Collaborate with us" link which directly links to this resolved task. Should that link be changed? (Apart from that I do not know who "us" and "we" is in the text and basically all links under "Design Resources" are dead on that page.)

@Aklapper Thanks and updated (removed link here).

Volker_E renamed this task from [EPIC] Enhance accessibility of OOjs UI & MediaWiki UI library / LSG / MediaWiki General to screen readers and color-deficient users to [EPIC] Enhance accessibility of OOUI & MediaWiki UI library / LSG / MediaWiki General to screen readers and color-deficient users.Sep 13 2018, 1:11 AM
Volker_E raised the priority of this task from High to Needs Triage.Feb 13 2019, 6:48 PM
Volker_E moved this task from Backlog to Done on the UI-Standardization-Kanban board.