[a11y] 9.1.4.10 Break content

[tschiebel]

audit: https://infinite.owncloud.com/s/PnaAukHGGsLnrMM

https://bitvtest.de/pruefschritt/bitv-20-web/bitv-20-web-9-1-4-10-inhalte-brechen-um

Personal

• [ ] With a browser window width of 1280 CSS pixels and a zoom magnification of 400%, the page content does not break. This means that all information and functions are not available without users having to scroll horizontally.

Shares

• [ ] If the browser window width is set to 1280 CSS pixels and the zoom magnification is set to 400%, only two columns are displayed in the table: "Name" and "Actions". "Actions". Other table columns are no longer accessible to users. To ensure that all table columns are visible even at higher zoom magnification, the table should either be the table should either be designed in such a way that it adapts to the available width or offer the option of scrolling horizontally through the table columns. scroll horizontally through the table columns.

Account

• [x] If the browser window width is set to 1280 CSS pixels and the zoom magnification is set to 400%, the content at the bottom of the page is cut off and is no longer accessible. no longer accessible.

[pascalwengerter]

Assigning @tbsbdr here since I need a decision on how to handle the tables on small screens

[pascalwengerter]

Assigning myself to test the general "break content" issues once more.

Having a reduced functionality in the table is fine according to @tbsbdr since the underlying actions are still available through the (right) sidebar on mobile

[tbsbdr]

• remove text from buttons "New" and "Upload" for like 1280@400%

• Shared and Spaces should not scroll horizontally (lets make it like in personal, i.e. stack and remove)

[kulmann]

@tbsbdr at 400% zoom on a 14 inch macbook the file list is not visible at all 🙈 see screenshot:

The table header is visible. Since the area above the table doesn't scroll I can't scroll the actual files into view. At 300% it still kind of works - I can see two rows of the file list (see next screenshot):

Do we have to fix this or can we assume a different browser window height if someone uses 400% zoom? 🤔

[tbsbdr]

uff, how about making the files top bar scrollable eg. if a certain zoom is reached? just thinking aloud..

[JammingBen]

Or just "unstick" the area above the table?

[tbsbdr]

eh, yes, thats what I wanted to say :)

[kulmann]

Yep, good idea. For normal desktop resolutions and 100% zoom level I like the sticky header. But for other situations that would be probably the easiest and most accessible solution.

[JammingBen]

Yep, good idea. For normal desktop resolutions and 100% zoom level I like the sticky header. But for other situations that would be probably the easiest and most accessible solution.

I'm just not sure if we should couple this to the zoom level. Some users have a default zoom setting of e.g. 110% or 125%. I feel like we still want to have the area sticky in this case.

Maybe couple it to the screen width? Because that's what basically happens with a zoom level of 400%: the screen width gets extremely small. So I suggest only doing this for screen widths <420px or <640px.

Edit: Or even better: couple this to the vertical window size.