fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

9.8K
active users

#accesskit

0 posts0 participants0 posts today
Matt Campbell<p>I'll be giving a talk this year at <a href="https://toot.cafe/tags/RustWeek" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>RustWeek</span></a>, in Utrecht, in the Netherlands. It will be basically an updated version of the talk I gave about <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> (<a href="https://accesskit.dev/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">accesskit.dev/</span><span class="invisible"></span></a>) at RustConf 2023. <a href="https://rustweek.org/talks/matt/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">rustweek.org/talks/matt/</span><span class="invisible"></span></a></p>
Monoka<p><span class="h-card" translate="no"><a href="https://mastodon.social/@Jonizulo_mstdn" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>Jonizulo_mstdn</span></a></span> With your suggestion on accessibility improvements in <span class="h-card" translate="no"><a href="https://floss.social/@gnome" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>gnome</span></a></span> , it might make sense to contact the developers of Newton, the <a href="https://mastodon.social/tags/Gnome" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Gnome</span></a> <a href="https://mastodon.social/tags/Wayland" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Wayland</span></a> native <a href="https://mastodon.social/tags/accessibility" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>accessibility</span></a> project. I don't know who is the best to contact there. The blog was written by Matt Campbell, but I don't know whom to best contact.</p><p><a href="https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">blogs.gnome.org/a11y/2024/06/1</span><span class="invisible">8/update-on-newton-the-wayland-native-accessibility-project/</span></a></p><p><a href="https://mastodon.social/tags/disability" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>disability</span></a><br><a href="https://mastodon.social/tags/linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>linux</span></a> <a href="https://mastodon.social/tags/accesskit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>accesskit</span></a></p>
Matt Campbell<p>Here's my latest update on Newton, the <a href="https://toot.cafe/tags/Wayland" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Wayland</span></a>-native, <a href="https://toot.cafe/tags/Flatpak" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Flatpak</span></a>-friendly <a href="https://toot.cafe/tags/accessibility" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>accessibility</span></a> project for the modern <a href="https://toot.cafe/tags/FreeDesktop" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>FreeDesktop</span></a> ecosystem, developed as part of <span class="h-card" translate="no"><a href="https://floss.social/@gnome" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>gnome</span></a></span> and funded by <span class="h-card" translate="no"><a href="https://mastodon.social/@sovtechfund" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>sovtechfund</span></a></span>. It's not ready for production yet, but this blog post includes a demo video and links to GNOME OS and Flatpak runtime builds you can try. As a bonus, because I'm integrating <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> into <a href="https://toot.cafe/tags/GTK" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>GTK</span></a>, GTK apps will finally have <a href="https://toot.cafe/tags/a11y" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>a11y</span></a> on Windows and macOS. <a href="https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">blogs.gnome.org/a11y/2024/06/1</span><span class="invisible">8/update-on-newton-the-wayland-native-accessibility-project/</span></a></p>
Dan Gero<p><a href="https://vocalounge.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> question. I'd like to recommend this to developers so they can make their projects more <a href="https://vocalounge.cafe/tags/accessible" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>accessible</span></a>. I noticed there's no documentation. Is it easy enough to learn without the need for documentation? If not, I'm hesitant to recommend something that I know developers are going to struggle with. It's tough enough asking them to make their apps accessible when they don't know much about us, let alone asking them to learn a new library with no docs. <a href="https://vocalounge.cafe/tags/Accessibility" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Accessibility</span></a> <a href="https://vocalounge.cafe/tags/Blind" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Blind</span></a> <a href="https://vocalounge.cafe/tags/VisuallyImpaired" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>VisuallyImpaired</span></a></p>
Jeff Fortin T.<p>There's a nice article out there by <span class="h-card" translate="no"><a href="https://mastodon.social/@jzb" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>jzb</span></a></span> summarizing <span class="h-card" translate="no"><a href="https://toot.cafe/@matt" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>matt</span></a></span>'s recent <a href="https://mastodon.social/tags/OSSNA" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>OSSNA</span></a> presentation on his work on <a href="https://mastodon.social/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> and "Newton", the new <a href="https://mastodon.social/tags/accessibility" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>accessibility</span></a> architecture for <a href="https://mastodon.social/tags/Wayland" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Wayland</span></a> and the future of <a href="https://mastodon.social/tags/GNOME" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>GNOME</span></a> &amp; <a href="https://mastodon.social/tags/Linux" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Linux</span></a> for assistive technologies: <a href="https://lwn.net/Articles/971541/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">lwn.net/Articles/971541/</span><span class="invisible"></span></a></p>
Matt Campbell<p>TIL; iOS allows accessibility elements to have non-rectangular bounds, using bezier paths. Clearly I should add that feature to my <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> cross-platform library (no, AccessKit isn't an Apple thing).</p>
Matt Campbell<p>Just saw that the Zed code editor (<a href="https://zed.dev/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">zed.dev/</span><span class="invisible"></span></a>) is now open source. It's written in Rust and has its own GUI toolkit, called GPUI. Doesn't look like they've done any work on accessibility yet. Hopefully they'll see fit to spend time integrating <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> soon.</p>
Matt Campbell<p>The <a href="https://toot.cafe/tags/Kivy" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Kivy</span></a> UI framework for <a href="https://toot.cafe/tags/Python" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Python</span></a> has been completely inaccessible to screen reader users for many years. But my colleague Arnold Loubriat is working on fixing that, using <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a>, particularly the Python bindings that he developed. There's still a long way to go on this project, but he has posted his work in progress here: <a href="https://github.com/DataTriny/kivy/tree/accesskit-demo" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/DataTriny/kivy/tree</span><span class="invisible">/accesskit-demo</span></a> And here's the tracking issue: <a href="https://github.com/kivy/kivy/issues/8547" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/kivy/kivy/issues/85</span><span class="invisible">47</span></a></p>
Matt Campbell<p>My new accessibility architecture is certainly Wayland-first, if not Wayland-only. It looks like the protocol that toolkits need to support is going to be way simpler than AT-SPI, and for <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a>, it would certainly be attractive to not have to bloat the code with either a new fallback protocol for X, or the old AT-SPI.</p>
Matt Campbell<p><span class="h-card" translate="no"><a href="https://tweesecake.social/@weirdwriter" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>weirdwriter</span></a></span> The AT-SPI protocol actually provides a way for ATs like Orca to automatically tell applications when accessibility needs to be enabled, as long as the desktop environment is correctly configured. I don't know if there are applications or toolkits that still don't support this mechanism. I know it's there because we just implemented it in <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a>.</p>
Matt Campbell<p>I want to do an overhaul of the <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> project website (<a href="https://accesskit.dev/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">accesskit.dev/</span><span class="invisible"></span></a>). The current site is kind of broken, but more than that, I want to do a static site with source in Git, not WordPress. The site contains a blog, but it's not just a blog. I haven't yet decided whether tutorial/narrative documentation should be part of the same site or on a separate docs site. The theme needs to prioritize accessibility but also not be ugly. I'd gladly pay someone to work on this.</p>
Matt Campbell<p>This came to mind just now because I was thinking about how I implemented integration between <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> and the Rust winit library. I did a direct integration in a fork of winit as a proof of concept, but rather than try very hard to get that code upstreamed, I ended up hacking around the lack of interest from the winit team by implementing Win32 subclassing on Windows and the ObjC runtime equivalent on macOS.</p>
Matt Campbell<p><span class="h-card" translate="no"><a href="https://mast.hpc.social/@fclc" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@<span>fclc</span></a></span> My understanding is that the best tool for programmers who need to use an alternative input method is Talon (<a href="https://talonvoice.com/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">talonvoice.com/</span><span class="invisible"></span></a>). I haven't yet tried it myself, but have chatted some with the lead developer; he's using my <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> library to make the Talon UI itself accessible.</p>
Matt Campbell<p>I should also thank everyone who has worked on PyO3 (<a href="https://pyo3.rs/v0.20.1/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pyo3.rs/v0.20.1/</span><span class="invisible"></span></a>), which makes it much easier to write Python extension modules in Rust. If Java had something equivalent, my Java bindings for <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> would probably be done already.</p>
Matt Campbell<p>Thanks to some excellent work by Arnold Loubriat, <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> now has Python bindings. <a href="https://pypi.org/project/accesskit/" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">pypi.org/project/accesskit/</span><span class="invisible"></span></a> This will be useful for GUI toolkits where the widgets are actually implemented in Python, such as Kivy or UIs on top of Pygame, as opposed to Python wrappers over C/C++ toolkits or platform widgets. Documentation is still pretty thin, but there's a pygame-based example in the source distribution.</p>
Matt Campbell<p>It's tempting to reduce the compiled size of one's software by excluding debug info from release builds. For end-user apps, it makes sense to exclude the debug info from the main distribution, and for proprietary software, to keep it to oneself. But for pre-built binaries of open-source libraries, like my <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> project, I think we have a duty to include debug info in the build and pass it along, so the ultimate app developer can debug issues in release builds if they need to. Thoughts?</p>
Matt Campbell<p>I can't stop wondering if, to truly meet my goals for the <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> project (<a href="https://github.com/AccessKit/accesskit" rel="nofollow noopener noreferrer" translate="no" target="_blank"><span class="invisible">https://</span><span class="">github.com/AccessKit/accesskit</span><span class="invisible"></span></a>), it will be necessary to rewrite it as a C library. Not a Rust library with a C API, but actually in C. I've had doubts before; you'd think the question would be settled by now. But two things prompted me to think about this again. 1/?</p>
Matt Campbell<p>I occasionally have to remind myself, when promoting my <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> project, that what really matters isn't whether developers use AccessKit, but that they implement accessibility one way or another. AccessKit isn't always the best solution. For example, it may be overkill for a project that's only targeting the browser but is still rendering the UI in a canvas. In that case, it may be simpler to create the hidden HTML elements directly rather than going through a layer of abstraction.</p>
Matt Campbell<p>I sometimes wonder if I'm solving a 2000s problem, so to speak, with my work on <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a>. That is, accessibility for non-web, desktop GUIs is quite an old problem by now, and AccessKit is simply trying to provide a reusable, toolkit-independent version of the sort of cross-platform accessibility abstraction that has existed (within browser engines and big GUI toolkits) for a couple of decades. It's certainly not a trendy thing to be working on. But still undeniably useful. 5/?</p>
Matt Campbell<p>Also, while Arnold Loubriat (the other main <a href="https://toot.cafe/tags/AccessKit" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>AccessKit</span></a> developer) and I were together in Albuquerque, where we met in person for the first time, we worked on the web platform adapter for AccessKit. This is specifically for web applications that render their UI to a canvas. We ran into an unexpected complication at the end, but the results so far are promising.</p>