screen reader logical reading order issue in dynamic page layout header section

[anuvenkatesh1]

Discussed in #3267

^{Originally posted by anuvenkatesh1 July 19, 2022}
One of our pages use the dynamic page layout component, which has the object header and content part just above the table.
The reading order is Title & Status (1, 2) -> all buttons -> then the other details (location/availability etc) are read in screen reader Browse mode. May be in the context of this test page is ok.

However, in the context of our page ( its about goals that we create and this page has the goal details. The object page header summarizes the details) and so it would make sense for a screen reader user to read all the details on the left first before moving on to the actions that can be taken on them ie in the context of the above dynamic page layout component, we want the title/status/updated/location/availability etc to be read first, before reading the buttons.
Please note that in our page we do not have the "collapse" button to collapse the header content area.

Below are the screenshots.

Due to current structure of the object header, unable to change the reading order. What's the workaround? How to achieve this?

[don-obrien]

@MarcusNotheis @Lukas742
Can we get an update on this one? I see the bug tag. Is this a bug, or does the reporter need advice on implementation?

[Lukas742]

Hi @don-obrien

I didn't find the time yet to take a deeper look into this, but I plan to check it out tomorrow. If we need more input from the reporter we will ask for the necessary information here and add the "author action" label.

[Lukas742]

Hi @anuvenkatesh1

I could not reproduce the reading order in your first example. Per default, so without setting e.g. tab-index or programmatically changing the focused element, only the interactive items are being focused and therefore read out.

What screen reader are you using and is there an option I have to enable somewhere to get the same behavior as you?

[GongRichard]

Hi @Lukas742,
You can use this page https://github.wdf.sap.corp/pages/xweb/team-goal/app/?templateId=1&mock#/detail?id=1 to reproduce this issue. I think @anuvenkatesh1 used JAWS as screen reader.
Thanks,
Richard

[Lukas742]

Hi @GongRichard

I could reproduce the described behavior using JAWS, but unfortunately I don't think there is much we can do. It seems like JAWS is reading the entries according to the DOM structure, which is the expected behavior in my opinion. Furthermore, it's the same behavior as with SAPUI5. As I'm not that familiar with JAWS I'm not sure if you can configure that behavior by e.g. setting attributes or changing the tab-index. However, this would then also have to be changed by the app developer (yourself), as all elements can be accessed via props or by passing the attributes/props to the component (e.g. Title) itself.

[don-obrien]

Is this still in author action? Do you need more info from @GongRichard ?

[Lukas742]

Hi @don-obrien

please refer to my last comment.

[GongRichard]

Hi @Lukas742 ,
I don't think this is a good solution for us. From fiori guideline https://experience.sap.com/fiori-design-web/dynamic-page-layout/, the title prop only puts title information. If we put all header content in the title, I think there will cause some other issues, for example, action buttons alignment with title content.

Hi @anuvenkatesh1,
From fiori design guideline, only title, sub-title and actions were put in header title area. Other infos were put in header content area. Our design meets the fiori guideline. I think we can hold on this issue and see whether there has customer will report a11y issue for this.

Thanks,
Richard

[Lukas742]

Hi @GongRichard

what exactly do you think is not a good solution? Our DynamicPage is implemented according to the UX guidelines (except for the Summary Line feature, for which you are welcome to create a feature request) or did you find something that is not?

Also, what do you mean with "put all header content in the title"? - How do you define "header content" and "title"?
If you mean the header prop of the DynamicPageTitle component with "title", then this is something I never mentioned. The DynamicPageTitle receives different props where you either can pass in components (like Title in the header prop), which logically can be fully controlled by you, or you can control the internally used components like the two Toolbars via props like actionsToolbarProps.

[GongRichard]

Hi @Lukas742 ,
Now we use DynamicPageTitle component, do you mean put all header content including title and subtitle to header prop of DynamicPageTitle?

Thanks,
Richard

[Lukas742]

No, that's not what I want you to do.
You need to use the DynamicPage in the intended way and set whatever customization you need on top of the props you pass into. Also, you didn't elaborate on what you mean with "title" or "header content" so until that is cleared up I unfortunately can't help you, but I'll try to summarize my findings and suggestions once more:

• The reading order of the JAWS screen reader is defined by the structure of the DOM, so we can't change that in our implementation.
• I don't know if JAWS offers an option to control this behavior e.g. via an attribute you can set to the element, or if it changes according to tab-index. If this is possible, then you can add these attributes to each of the components you pass into the DynamicPageTitle or DynamicPageHeader.
  Small example with custom tab-index for the heading and each button:

<DynamicPageTitle
  actions={
    <>
      <Button tabIndex={/*some value*/}>
        Edit
      </Button>
      <Button tabIndex={/*some value*/}>
        Delete
      </Button>
    </>
  }
  header={<Title tabIndex={/*some value*/}>Header Title</Title>}
/>

• As stated in our documentation, you should only use the DynamicPageTitle component as value for the headerTitle prop of the DynamicPage and only DynamicPageHeader for the headerContent prop to preserve the intended design.

[GongRichard]

Hi @Lukas742 ,
Thanks for your suggestions. Change tab-index will cause axe error. I think the only way is to change the DOM structure.
As I replied in the above thread, I also think our implementation meets fiori guideline. I suggested to hold on this issue until customer reports this as a11y issue to us.
Thanks,
Richard

[github-actions]

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Inactive issues will be closed after 7 days. Thanks.

[github-actions]

Hey there, it's me again! I am going close this issue to help our maintainers focus on the current development roadmap instead. If the issue mentioned is still a concern, please open a new ticket and mention this old one.

[don-obrien]

@Lukas742 , an SFSF customer has complained about the same thing. Can you please revisit this and plan for addressing it?

[Lukas742]

Hi @don-obrien

as we are waiting for the outcome of the internal discussion, we will keep this issue closed until the decisions are made.