Reader mode for XWiki

Development
,
#1

Good morning!
When reading through a few web UI feeds, I realized that Firefox had a reader mode implemented by default.
I propose to spend time onto implementing a reader mode into the XWiki platform.

What is a reader mode?

Most web browsers have a “reader mode" that strips away non-essential content, providing a simpler text-based presentation. Toggling reader mode typically removes ads, formatting, and other distracting elements, leaving behind the text (and in most cases, images).

From How Browser "Reader Modes" Improve the Experiences of People with Disabilities

Example of the Firefox reader mode used on a topic from this forum:
readerModeOFF
readerModeON

Why is it useful?

  • Usability: easier for any user to focus on the content of the page. Possibility to implement browser-level preferences support (dark theme, high contrast, reduced motion, …) later on.
  • Accessibility: Especially useful for attention-related disorders : easier to keep focus on the content. Makes it possible to support high contrast mode (high contrast on all the XWiki UI would take a lot of choices and work) for impaired vision users.

Why isn’t reader mode available for XWiki yet?
Reader mode so far are tools provided by web browsers that parse the page, and return a simplified version of it where only the main content is kept. However, the current XWiki architecture, most of the time, doesn’t give results good enough so that the reader mode is supported. Here is an example of a page from dev.xwiki.com that should easily be supported by Firefox’ reader mode, but isn’t (note that there isn’t an icon to turn on reader mode next to the bookmark button in the address bar):
noReaderMode

On the other hand the welcome page for XWiki-contrib is supported by Firefox reader mode:
image

How would we support reader mode?
I see two solutions for reader mode in XWiki:

  1. Improve XWiki’s page architecture with landmarks and more semantic markup, and hope that at one point it gets good enough so that the browser’s reader modes will be available for most pages.
  2. Develop a reader mode for XWiki and add a toggler on view pages (button and/or shortcut). Only include the page title (maybe the last modification info) and the content of the page. That’d leave out everything like: panels, breadcrumb, header, footer, drawer menu, … And possibly remove most of the color theme CSS to only keep the strict minimum (might be too difficult/heavy).

I think the second one would be best:

  • Pros:
    • Not reliant on the browser and it’s algorithm to support the reader mode, there won’t be issues where a document doesn’t have a reader mode on some web browsers.
    • We can easily control the content displayed in reader mode, unlike when using the browser’s reader modes that work well in most cases but don’t have a hard coded rule to format XWiki pages.
    • Quite easy to implement a working solution
  • Cons:
    • XWiki needs to handle the feature, instead of relying on the browsers for development and maintenance.
    • Need a bit more time to implement user preferences and other additional functionalities that are available in browser’s screen readers.

I think this second solution could be considered as a new feature for the flamingo skin.

This is not required for WCAG validation. I personally think it’d be a nice feature to support on any document oriented knowledge base like XWiki.

This is just a first draft to get an idea of the community interest in such a feature. If the feedback is positive, I’ll take time to make a design page with details about styles, supported features and implementation, then start a new discussion to make sure it’s okay afterwards.

What do you think of this idea?

What would be the correct way to contribute for this new feature (xwiki-platform ticket, contrib project, …) ?

EDIT:
Should we add a shortcut to trigger the plain viewing style?
Should we add a UI element on view page (button) to trigger the plain viewing style?

#2

We already have a reader mode :slight_smile:

For example: Project Governance - XWiki (notice the suffixing with ?xpage=plain&htmlHeaderAndFooter=true&outputTitle=true)

See Standard URL Format (XWiki.org) for more details.

#3

What we don’t have is an easy for users to trigger it.

#4

Nice! I didn’t know about it, thanks for the help!

I think it’d be really nice for users to be able to switch to this mode without knowing the XWiki Dev doc for URL format. :slight_smile:

Updated proposal subject (since the above questions are not really relevant in regards to the conversation)

Should we add a shortcut to trigger the plain viewing style?
Should we add a UI element on view page (button) to trigger the plain viewing style?

I’m +1 for both, the first one would be useful for power users and the second would make the functionality known to regular users.

#5

We have a lot of tweaks to make our xwiki more accessible and to gain for BITV (german wcag). (Some you will find in jira tickets with the label accessibility.)

We inserted some regions into the html. I think the one that will be most important is <main> surrounding the article itself. I think this is the reason that we do have the reader option shown and working.

Maybe a quick try worth before trying other things?
Simpel

PS: If that’s not working for you I can go into further investigation at our wiki.

#6

This is good (hadn’t realized)! Thanks for reporting Loading...

Keep them coming!

#7

Looks like I wasn’t precise. We don’t insert a <main> tag but add a role:


let mainContent = document.querySelector("#mainContentArea > .xcontent");
mainContent.setAttribute('role', 'main');

Trying this at console could give a quick answer whether this is enough for a reader option.

#8

The <main> tag has the default aria-attribute role=“main”. If it works with role=“main”, it should work for the <main> tag at least as well.

I didn’t check reader mode with those yet, but adding landmarks and a main tag is already in some PRs I wish to merge soon (still being reviewed <-> fixed):

Thanks for your feedback! :slight_smile: