[Feature Request]: Allow to hide next and previous buttons in PaginationNav

[radarfox]

The problem

We would like to migrate from our custom pagination component to PaginationNav. Our custom component hides next/previous button on the first/last page, instead of disabling it, like the current PaginationNav does.

The solution

Allow to hide next and previous buttons, somehow like this:

<PaginationNav hideDisabledControls />

When the next/previous button is hidden, one more button linking to a page should by displayed. That way the width of the pagination will be the same on all pages. For example, the first page of pagination for itemsShown: 4 and totalItems: 9 currently looks like this:

< 1 2 ... 9 >

With hideDisabledControls set it would become:

1 2 3 ... 9 >

Examples

https://research.ibm.com/people

Application/PAL

https://research.ibm.com/

Business priority

Medium Priority = upcoming release but is not pressing

Available extra resources

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

[tay1orjones]

Could you share more of the design and UX evidence to justify this change?

My understanding of the initial development of this component is that leaving the element in the DOM is preferred so that there is consistency in the DOM for screenreader users. It supports the idea that screenreaders can read the button as "button (dimmed)" to convey the disabled status.

For these reasons we probably won't modify this but I'm curious to know if you have any additional rationale. For instance, if we can show that removing the buttons would improve the screenreader experience, I think at that point we could reconsider the design.

[radarfox]

Could you share more of the design and UX evidence to justify this change?

I will link you up with our design team, so they can explain you the reasoning and design specs behind this. I will contact you over Slack, since this will involve confidential information.

[justinbrussIBM]

I'm working on a component which adds 'pagination' to the 'Aside' area of the 'Leadspace with Foreground Asset' which is currently available in C4AEM.

Initially, I built this component without the 'arrows' being displayed since the component is limited to 4 pages max and the 'Aside' area is tight on space.

I've attended Carbon Design Office Hours and our initial conversation seemed to indicate that adding the ability to hide the 'Next' and 'Previous' arrows wouldn't be detrimental to accessibility since the amount of page is limited.

I haven't contributed to Carbon yet, but I could look into this as an addition to the 'Pagination' component's options.