3 ms·

The reason browsers use the document as a building block is to provide a consistent and accessible UI to everyone using your site. This is the exact same thing

by snek 7y ago

The reason browsers use the document as a building block is to provide a consistent and accessible UI to everyone using your site. This is the exact same thing that Windows, Apple, Android, etc do with their UI frameworks that they recommend you use. It also provides the ability for websites to safely degrade on older browsers because unknown elements can still be rendered in the correct hierarchy. Now in both cases, you can just make your app a fullscreen canvas or opengl/metal viewport or whatever and manually render everything to that while manually handling user input, but you lose interactivity, accessibility, extensibility, etc.

flohofwoe 7y ago
Platforms should provide the necessary low-level APIs to hook into their accessibility- etc... features without having to use their high-level UI frameworks, and they should provide lower-level services like high-quality text rendering. Mostly this already works, I can open a standard file dialog, or copy data into or out of the system-wide clipboard. If there are any APIs for accessibility missing (e.g. for hooking into screen-readers), I would consider that a bug on that particular platform. There's no reason that applications which use the system UIs should behave any different from applications using custom UIs.
- snek 7y ago
  There are ARIA attributes which let you customize the advertised meaning/intent of an element, but there is nothing to, say, mark that a particular location on the page should be considered a button. As far as I'm aware, this matches how Android, Windows, iOS, etc work. There are so many parts that go into the accessibility of an element, handling tab index, handling keyboard input, handling screenreaders, spoken voice prompting, etc, that a custom solution usually ends up being detrimental to the user's experience.
- saagarjha 7y ago
  There's no way a platform can provide accessibility for arbitrary pixels you throw onto a screen. You could, by yourself, using the low-level accessibility APIs, but you likely won't since it's a lot of work. Hence the push for using platform UI components: they inform the framework of your intention, and in return this information helps it provide you with better accessibility.

by snek 7y ago

flohofwoe 7y ago

Platforms should provide the necessary low-level APIs to hook into their accessibility- etc... features without having to use their high-level UI frameworks, and they should provide lower-level services like high-quality text rendering. Mostly this already works, I can open a standard file dialog, or copy data into or out of the system-wide clipboard. If there are any APIs for accessibility missing (e.g. for hooking into screen-readers), I would consider that a bug on that particular platform. There's no reason that applications which use the system UIs should behave any different from applications using custom UIs.

snek 7y ago
There are ARIA attributes which let you customize the advertised meaning/intent of an element, but there is nothing to, say, mark that a particular location on the page should be considered a button. As far as I'm aware, this matches how Android, Windows, iOS, etc work. There are so many parts that go into the accessibility of an element, handling tab index, handling keyboard input, handling screenreaders, spoken voice prompting, etc, that a custom solution usually ends up being detrimental to the user's experience.
saagarjha 7y ago
There's no way a platform can provide accessibility for arbitrary pixels you throw onto a screen. You could, by yourself, using the low-level accessibility APIs, but you likely won't since it's a lot of work. Hence the push for using platform UI components: they inform the framework of your intention, and in return this information helps it provide you with better accessibility.