6 ms·

Hopefully this starts supporting accessibility tools before it gets too much traction and people start shipping inaccessible apps. The WebAssembley output demos

by whylo 5y ago

Hopefully this starts supporting accessibility tools before it gets too much traction and people start shipping inaccessible apps. The WebAssembley output demos on the homepage just render to a <canvas> and are completely inaccessible with any of the usual tools (screen reader, keyboard-only, voice dictation etc) but there's a GitHub issue (https://github.com/slint-ui/slint/issues/32 https://github.com/slint-ui/slint/issues/32) so fingers crossed.

torginus 5y ago
The thing that (the generally excellent) MS UI Automation API has taught me is that making the UI accessible makes it testable and vice versa. Since any serious software projects needs tests, having a good accessibility story is paramount to delivering high-quality applications.
robin_reala 5y ago
Yeah, a UI toolkit that doesn’t have even basic accessibility bindings is basically illegal to use for commercial products in multiple major countries now. No specific shame on Slint (everyone has their own roadmaps) but when even big companies are failing* in this way it does seem like we’ve got a long way to go as an industry. * Flutter has no accessibility bindings on the web and therefore falls under the same “illegal” category.
- nindalf 5y ago
  I’m surprised by how much progress we’ve made in this area. I used to make android apps circa 2013-15. Accessibility was an afterthought, a nice to have. Reading the SwiftUI docs in 2022, it’s front and centre. They tutorial covers accessibility soon after “hello world”. Every module of the tutorial has a section on setting the right accessibility info, rather than a single, optional accessibility tutorial. It makes me happy that doing the right thing is the default. I’m planning on making a small productivity app just for myself, but it’ll be 100% accessible simply because they’ve made it so easy.
  - paxswill 5y ago
    Integrating accessibility into the tutorial is fantastic, but I’d also attribute it to Apple emphasizing accessibility in their developer documentation for a long time. I remember one of the early Interface Builder tutorials explaining accessibility pretty early on.
  - mirashii 5y ago
    I wouldn’t attribute this to progress. iOS and macOS have always heavily prioritized accessibility. For Google, you can see in this example and in the flutter example that accessibility is an after thought.
  - ATsch 5y ago
    The last time I spoke to a blind person it was quite a different picture, she was more or less forced to exclusively use apple products because nobody else took accessibility seriously enough.
- easrng 5y ago
  Flutter does handle accessibility on the web, but not very well. You need to press a button hidden from non-screenreader users and then Flutter will make a tree of dummy elements with aria attributes that let you use the app. You can see this if you use a screenreader or your browser of choice's accessibility tree inspector on the demo app.
  - robin_reala 5y ago
    Ah, OK, looks like they’ve progressed a bit since I evaluated it. Thanks for the update.
- badsectoracula 5y ago
  > a UI toolkit that doesn’t have even basic accessibility bindings is basically illegal to use for commercial products in multiple major countries now Any sources for that? I've never seen such a claim outside of Hacker News. A quick Google search i did about it only shows some court cases in U.S. (and in those cases it seems to be up to the judge with many failing). The closest is a requirement from EU in 2018 that web sites by the member states' government (ie. it is only for government web sites) has to be accessible. That makes sense, but it only covers government web sites specifically, not any other use for a toolkit (e.g. desktop apps) or even private sites.
  - robin_reala 5y ago
    Sure. In the US is the ADA which stipulates “reasonable accomodations” to be made for users with disabilities. You could argue that providing e.g. a phone system as an alternative helps to satisfy this, but it’s debatable, and has been debated backwards and forwards in the US court system. In Canada, from 2021-01-01 the AODA (Accessibility for Ontarians with Disabilities Act) specifically calls out WCAG 2.0 double-AA (with a few, very minor, changes around closed captioning) as the minimum for both public and private sector businesses. Israel also has a minimum requirement of WCAG 2.0 double-AA codified into law. Norway, while not specifically mentioning a standard or guideline, has accessibility requirements interpreted by their regulator to meet WCAG 2.1 double-AA. And the whole of the EU will gain a minimum requirement of WCAG 2.1 double-AA for the private sector from 2025-06-28 (that’s already the case for the EU public sector). Something to be aware of if you’re purchasing software / white-label systems now. While it’s a little out of date now, a good starting point is https://www.w3.org/WAI/policies/ https://www.w3.org/WAI/policies/.
    - badsectoracula 5y ago
      Hoes do all those translate to UI toolkits not having accessibility functionality being illegal though? It is largely a legalese infodump that makes it very hard to parse, but i skimmed through the EU proposal (most of its requirements being at the annex) and it largely seems to be for websites or for very specific uses where it'd make sense (Check-in stations, ticket stations, ATMs, E-commerce sites, etc). The closest to a more general requirement would be the requirement for operating systems to provide functionality like text-to-speech (it mentions "more than one sensory channel" so i assume that would fit), zooming, etc but the wording on that seems to be about the complete package - so i guess if that proposal passes, a store wouldn't be able to sell, e.g., a computer with Linux and IceWM preinstalled as the only desktop (no text to speech there). When you wrote that UI toolkits without accessibility functionality being illegal was there anything more clear and specific or is it this just more of a "just in case" scenario?
charcircuit 5y ago
It should be possible with a good screen reader. It can read to the icons and text on the page to you. It might be hard to know which boxes are clickable, but that applies to using it normally too.
- robin_reala 5y ago
  A screenreader doesn’t literally read the screen, it reads the accessibility tree that apps build for their interfaces. If your user interface kit doesn’t create an accessibility tree then your users’ screenreaders are completely lost at sea.
  - badsectoracula 5y ago
    Considering year old mobiles are able to perform on-the-fly language translations in photos even via awful cameras, i find it weird that screenreaders still rely on such hints.
    - gostsamo 5y ago
      OCR is relatively easy, but the accessibility information is not only that. There are the types of elements, the possible interactions and the changes on the screen. Also, it gives the ability to skip unnecessary information. Using ml for all of that is taxing and probably not very practical until the invention of AGI.
      - badsectoracula 5y ago
        I wasn't referring to just OCR, check my other comment.
    - kroltan 5y ago
      Delete every CSS declaration (both inline or stylesheets) from every website and see how easy it is to read them. Not very, huh? Same deal with accessibility. You can't "just OCR stuff" without losing all the visual meaning in a page. Just like we use borders and paddings and colors to hierarchize information, screenreaders use an information hierarchy too so users can conveniently navigate around.
cnity 5y ago
To be clear, using canvas elements for UI is not inherently inaccessible so long as some accessible content on the page is also available to screen readers. Slint could in theory additionally render a kind of keyboard accessible overlay with invisible page elements, for example. Edit: accessible -> inaccessible
- whylo 5y ago
  Sure - that's the approach Google have taken with Docs, which switched to canvas-based rendering last year (https://thenewstack.io/google-docs-switches-to-canvas-rendering-sidelining-the-dom/ https://thenewstack.io/google-docs-switches-to-canvas-render...). It's definitely not for the faint of heart though.
Cthulhu_ 5y ago
I don't think tools like this should be used to make websites / webapps, period; good enough for demo purposes, but just because you can, doesn't mean you should. Just make a good website / webapp, you get a lot of accessibility for free if you use semantically correct HTML and sprinkle in accessibility hints where needed. Likewise, if you're building apps, prefer to build them using native toolkits if you value accessibility. The major platforms have it built in. When building an app, did you ever consider VoiceOver gestures [1]? Providing a readable text for the text-to-speech engine as an alternative to a UI element? https://support.apple.com/guide/iphone/learn-voiceover-gestures-iph3e2e2281/ios https://support.apple.com/guide/iphone/learn-voiceover-gestu...
RobLach 5y ago
This is an important factor. Accessibility only gets harder to integrate with time and is fundamental to any serious general long-term usage.

by whylo 5y ago

torginus 5y ago

The thing that (the generally excellent) MS UI Automation API has taught me is that making the UI accessible makes it testable and vice versa. Since any serious software projects needs tests, having a good accessibility story is paramount to delivering high-quality applications.

robin_reala 5y ago

Yeah, a UI toolkit that doesn’t have even basic accessibility bindings is basically illegal to use for commercial products in multiple major countries now. No specific shame on Slint (everyone has their own roadmaps) but when even big companies are failing* in this way it does seem like we’ve got a long way to go as an industry. * Flutter has no accessibility bindings on the web and therefore falls under the same “illegal” category.

nindalf 5y ago
I’m surprised by how much progress we’ve made in this area. I used to make android apps circa 2013-15. Accessibility was an afterthought, a nice to have. Reading the SwiftUI docs in 2022, it’s front and centre. They tutorial covers accessibility soon after “hello world”. Every module of the tutorial has a section on setting the right accessibility info, rather than a single, optional accessibility tutorial. It makes me happy that doing the right thing is the default. I’m planning on making a small productivity app just for myself, but it’ll be 100% accessible simply because they’ve made it so easy.
- paxswill 5y ago
  Integrating accessibility into the tutorial is fantastic, but I’d also attribute it to Apple emphasizing accessibility in their developer documentation for a long time. I remember one of the early Interface Builder tutorials explaining accessibility pretty early on.
- mirashii 5y ago
  I wouldn’t attribute this to progress. iOS and macOS have always heavily prioritized accessibility. For Google, you can see in this example and in the flutter example that accessibility is an after thought.
- ATsch 5y ago
  The last time I spoke to a blind person it was quite a different picture, she was more or less forced to exclusively use apple products because nobody else took accessibility seriously enough.
easrng 5y ago
Flutter does handle accessibility on the web, but not very well. You need to press a button hidden from non-screenreader users and then Flutter will make a tree of dummy elements with aria attributes that let you use the app. You can see this if you use a screenreader or your browser of choice's accessibility tree inspector on the demo app.
- robin_reala 5y ago
  Ah, OK, looks like they’ve progressed a bit since I evaluated it. Thanks for the update.
badsectoracula 5y ago
> a UI toolkit that doesn’t have even basic accessibility bindings is basically illegal to use for commercial products in multiple major countries now Any sources for that? I've never seen such a claim outside of Hacker News. A quick Google search i did about it only shows some court cases in U.S. (and in those cases it seems to be up to the judge with many failing). The closest is a requirement from EU in 2018 that web sites by the member states' government (ie. it is only for government web sites) has to be accessible. That makes sense, but it only covers government web sites specifically, not any other use for a toolkit (e.g. desktop apps) or even private sites.
- robin_reala 5y ago
  Sure. In the US is the ADA which stipulates “reasonable accomodations” to be made for users with disabilities. You could argue that providing e.g. a phone system as an alternative helps to satisfy this, but it’s debatable, and has been debated backwards and forwards in the US court system. In Canada, from 2021-01-01 the AODA (Accessibility for Ontarians with Disabilities Act) specifically calls out WCAG 2.0 double-AA (with a few, very minor, changes around closed captioning) as the minimum for both public and private sector businesses. Israel also has a minimum requirement of WCAG 2.0 double-AA codified into law. Norway, while not specifically mentioning a standard or guideline, has accessibility requirements interpreted by their regulator to meet WCAG 2.1 double-AA. And the whole of the EU will gain a minimum requirement of WCAG 2.1 double-AA for the private sector from 2025-06-28 (that’s already the case for the EU public sector). Something to be aware of if you’re purchasing software / white-label systems now. While it’s a little out of date now, a good starting point is https://www.w3.org/WAI/policies/ https://www.w3.org/WAI/policies/.
  - badsectoracula 5y ago
    Hoes do all those translate to UI toolkits not having accessibility functionality being illegal though? It is largely a legalese infodump that makes it very hard to parse, but i skimmed through the EU proposal (most of its requirements being at the annex) and it largely seems to be for websites or for very specific uses where it'd make sense (Check-in stations, ticket stations, ATMs, E-commerce sites, etc). The closest to a more general requirement would be the requirement for operating systems to provide functionality like text-to-speech (it mentions "more than one sensory channel" so i assume that would fit), zooming, etc but the wording on that seems to be about the complete package - so i guess if that proposal passes, a store wouldn't be able to sell, e.g., a computer with Linux and IceWM preinstalled as the only desktop (no text to speech there). When you wrote that UI toolkits without accessibility functionality being illegal was there anything more clear and specific or is it this just more of a "just in case" scenario?

charcircuit 5y ago

It should be possible with a good screen reader. It can read to the icons and text on the page to you. It might be hard to know which boxes are clickable, but that applies to using it normally too.

robin_reala 5y ago
A screenreader doesn’t literally read the screen, it reads the accessibility tree that apps build for their interfaces. If your user interface kit doesn’t create an accessibility tree then your users’ screenreaders are completely lost at sea.
- badsectoracula 5y ago
  Considering year old mobiles are able to perform on-the-fly language translations in photos even via awful cameras, i find it weird that screenreaders still rely on such hints.
  - gostsamo 5y ago
    OCR is relatively easy, but the accessibility information is not only that. There are the types of elements, the possible interactions and the changes on the screen. Also, it gives the ability to skip unnecessary information. Using ml for all of that is taxing and probably not very practical until the invention of AGI.
    - badsectoracula 5y ago
      I wasn't referring to just OCR, check my other comment.
  - kroltan 5y ago
    Delete every CSS declaration (both inline or stylesheets) from every website and see how easy it is to read them. Not very, huh? Same deal with accessibility. You can't "just OCR stuff" without losing all the visual meaning in a page. Just like we use borders and paddings and colors to hierarchize information, screenreaders use an information hierarchy too so users can conveniently navigate around.

cnity 5y ago

To be clear, using canvas elements for UI is not inherently inaccessible so long as some accessible content on the page is also available to screen readers. Slint could in theory additionally render a kind of keyboard accessible overlay with invisible page elements, for example. Edit: accessible -> inaccessible

whylo 5y ago
Sure - that's the approach Google have taken with Docs, which switched to canvas-based rendering last year (https://thenewstack.io/google-docs-switches-to-canvas-rendering-sidelining-the-dom/ https://thenewstack.io/google-docs-switches-to-canvas-render...). It's definitely not for the faint of heart though.

Cthulhu_ 5y ago

I don't think tools like this should be used to make websites / webapps, period; good enough for demo purposes, but just because you can, doesn't mean you should. Just make a good website / webapp, you get a lot of accessibility for free if you use semantically correct HTML and sprinkle in accessibility hints where needed. Likewise, if you're building apps, prefer to build them using native toolkits if you value accessibility. The major platforms have it built in. When building an app, did you ever consider VoiceOver gestures [1]? Providing a readable text for the text-to-speech engine as an alternative to a UI element? https://support.apple.com/guide/iphone/learn-voiceover-gestures-iph3e2e2281/ios https://support.apple.com/guide/iphone/learn-voiceover-gestu...

RobLach 5y ago

This is an important factor. Accessibility only gets harder to integrate with time and is fundamental to any serious general long-term usage.