Search results

Meryl Evans, CPACC 🦻 @MerylEvans@mastodon.social
Public

Thank you, TEDx for viewing as an important topic and for making it an Editor’s Pick. Thank you Shannah Hayley and TEDxPlano for the opportunity! Thanks to Thomas Logan, Makoto Ueki, and Ashley Coffey for making the talk possible

youtu.be/Wx8gGP79QTY

The pandemic's influence on accessibility | Meryl Evans | TEDxPlano

While no one wanted a pandemic to happen, Meryl Evans points out that history has shown events like this can lead to changes for the better. For her, the ris...

www.youtube.com · YouTube

0
0
0
0
0
0
Ollie Boermans @ollicle@mastodon.social
Public

Most certainly not just me! <details> in popover (opened with popovertarget) breaks keyboard navigation.

Firefox: bugzilla.mozilla.org/show_bug.
Chrome: issues.chromium.org/issues/424
My test case: ollicle.com/jot/details-in-pop

The workaround in both browsers is to use JavaScript `showPopover()` to open the popover, thanks @keithamus

Safari is the good guy in this particular occasion

Update: showPopover is not the workaround I hoped for:

1972609 - Tab navigation unexpected behavior for summary/details inside popover

ASSIGNED (mozilla) in Core - DOM: Core & HTML. Last updated 2025-08-29.

bugzilla.mozilla.org

0
0
0
Michael Hanscom @djwudi@tenforward.social
Public

Here’s my / post (updated 5/25/24):

Hi! I’m Michael, but can frequently be found online as “djwudi”.

Grew up in , now exist just south of most of the time.

Currently work in as the Program Manager at Highline College.

I’m a / fan. is my home fandom, and I volunteer for @norwescon, a local regional fan-run con, and for @SeattleWorldcon2025 .

I read a lot of SF . Trek novels are my go-to “comfort food”. I’m slowly working my way through all the Best Novel winners, and every year read all of the nominees for the before the annual award ceremony at Norwescon.

Speaking of the Philip K. Dick Award and , as of (2023), I am the award ceremony coordinator for Norwescon. This means I oversee the award ceremony and work with nominated authors and their agents as we invite them to attend the ceremony.

I’m one of the many Seattleites who “used to be a ”. For me, it was about a decade in in the late ‘90s/early ‘00s, primarily at The Lost Abbey and Gig’s Music Theatre. Focused on alternative genres: goth/industrial/synth pop/ebm/techno/etc. These days I occasionally pop up on Twitch, and semi-regularly DJ the Thursday night dance at Norwescon.

Though recently more on the fringes, I try to be part of the (Seattle / ) community whenever possible. I used to be a regular at The Vogue (on 12th), and these days try to get out to the Mercury once every month or two.

/ user by choice, Windows user if paid.

Oh, and: 51, white, cis, male, statistically straight, healthy, white-collar employed, not rich but comfortably not poor, married, homeowner, neurotypical (as far as I know). In other words, living with a lot of that I try to be aware of and use for good.

- - 🖖🏻

0
0
0
Coral 😷 @coral@kind.social
Public

Redoing my intro on my shiny new instance:

Hi, I'm Coral (NOT Carol)

In real life I love , , crafting, cozy video games, biking, reading, and gardening. I have a spouse, two , and two

At work I'm into , , (don't talk to me about DEI without the A), and . I'm a librarian, electrical engineer, and former prof, now doing via for an

so

0
0
0
Coral @coral@code4lib.social
Public

Hi, I'm Coral (NOT Carol)

In real life I love , , crafting, cozy video games, biking, reading, and gardening. I have a spouse, two , and two . We're moving to upstate NY.

At work I'm into , , (don't talk to me about DEI without the A), and . I'm a librarian, electrical engineer, and former prof, now doing via for an

Still dealing w/ and knowledge that

0
0
0
Paul Haddad :tapbots_logo: @paul@tapbots.social
Public

When the movies about the downfall of Apple are written, screenwriters will disagree about when it started. Jobs death, Cook takeover, Ive taking control, Ive leaving, Dye doing whatever the hell he's doing, Swift/UI engineers taking over, etc.. etc.. etc…

To me it'll always be this.

0
0
0
Steve Faulkner @SteveFaulkner@mastodon.social
Public

👀 @w3cWorld Wide Web Consortium WAI invites you to comment on the updated:
W3C Accessibility Guidelines (WCAG) 3.0 Working Draft

w3.org/TR/wcag-3.0/

W3C Accessibility Guidelines (WCAG) 3.0

W3C Accessibility Guidelines (WCAG) 3.0 will provide a wide range of recommendations for making web content more accessible to users with disabilities. Following these guidelines will address many of the needs of users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of any of these disabilities. These guidelines address the accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other Web of Things devices. The guidelines apply to various types of web content, including static, dynamic, interactive, and streaming content; audiovisual media; virtual and augmented reality; and alternative access presentation and control. These guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

www.w3.org

0
0
0
Web Accessibility Initiative @wai@w3c.social
Public

W3C WAI invites you to comment on the updated W3C Accessibility Guidelines (WCAG) 3.0 Working Draft. This in-progress draft has more guidelines, requirements, and assertions ready for review. There are some sections that are not yet updated.

For review questions and how to comment, see the section 'About this draft'.

WCAG 3 Working Draft: w3.org/TR/wcag-3.0/

For background, timeline, and up-to-date information, see WCAG 3 Introduction: w3.org/WAI/wcag3

W3C Accessibility Guidelines (WCAG) 3.0

W3C Accessibility Guidelines (WCAG) 3.0 will provide a wide range of recommendations for making web content more accessible to users with disabilities. Following these guidelines will address many of the needs of users with blindness, low vision and other vision impairments; deafness and hearing loss; limited movement and dexterity; speech disabilities; sensory disorders; cognitive and learning disabilities; and combinations of any of these disabilities. These guidelines address the accessibility of web content on desktops, laptops, tablets, mobile devices, wearable devices, and other Web of Things devices. The guidelines apply to various types of web content, including static, dynamic, interactive, and streaming content; audiovisual media; virtual and augmented reality; and alternative access presentation and control. These guidelines also address related web tools such as user agents (browsers and assistive technologies), content management systems, authoring tools, and testing tools.

www.w3.org

0
0
0
Mark Wyner Won’t Comply :vm: @markwyner@mas.to
Public

Y’all. I did it. I just published my very first macOS app. 🎉

It’s a color contrast checker for accessibility compliance. I designed and built it for myself, but I’m also gifting it to the world.

It’s not in the App Store, but it is signed for safety. And it will let you know when there’s an update.

I’m a little giddy about it. 😊

UPDATE: new versioning system. v1.2 is available now.

ratioapp.markwyner.com

Ratio App: Accessibility Color Contrast Checker for macOS

Accessibility color contrast checker for macOS with support for WCAG and APCA.

ratioapp.markwyner.com · Mark Wyner

0
0
0
0
0
0
Accessibility Club @a11yclub@mastodon.social
Public

📣 Big news: is getting its own meetup, and it's happening on 3 September (in one week). 💥

On the initiative of Josefine Schaefer and @sweckenmannSonja Weckenmann, with inaugural talks by @NinaGerlingNina en dé­tail and Detlev Fischer, generously hosted by slashwhy.

All individuals with any level of knowledge are welcome to attend; participation is free (but registration is required). All details at accessibility.club/event/acces

Who are we meeting in Hamburg next week?

Accessibility Club Meetup #12

An informal meetup for web workers & designers about web accessibility & assistive technology — September 3rd, 2025, Hamburg

accessibility.club

0
0
0
Dion @diondiondion@indieweb.social
Public

folks, what's your take on this UI pattern that's quite common on social platforms:

A button with a verb label (e.g. "Follow") that, after the button was pressed, changes to an adjective describing the status (e.g. "Following"), rather than being explicit about the action it'll perform when pressed again (e.g. "Unfollow").

Do you find this problematic in practice?

Screenshot from Instagram showing a list of accounts with a Follow button in each row. Some of the buttons are de-emphasized and say "Following". The account names and avatars are blurred out for privacy.
0
0
0
Mark Wyner Won’t Comply :vm: @markwyner@mas.to
Public

@fremachucaFrederico Machuca @carapaceSimon Forman @adamAdam Newbold :usa_distress:

Most def. Thanks for tagging me in!

inclusive-components.design/

tarnoff.info/

silviamaggidesign.com/ (@silviamaggi)

neurodiversity.design/

colorandcontrast.com/

gerireid.com/blog/wcag-design-

bitsofco.de/the-accessibility-

accessiblenumbers.com/

whocanuse.com/

I’ve also been designing/building accessible interfaces for a very long time. I should write about it more. But I did write a couple of pieces:

markwrites.io/build-a-simple-c

Inclusive Components

A blog trying to be a pattern library. All about designing inclusive web interfaces, piece by piece.

inclusive-components.design · Inclusive Components

0
0
0
0
0
0
Adrian Roselli @aardrian@toot.cafe
Public

In the past, Safari folks moved on the pile of `display` bugs after I started filing web compat PRs to change support notes.

Trying these as bug reports first, before I make PRs to change support:
• github.com/mdn/browser-compat-
• github.com/mdn/browser-compat-
• github.com/mdn/browser-compat-
• github.com/mdn/browser-compat-

What type of issue is this? Incorrect support data. What information was incorrect, unhelpful, or incomplete? Support for the <del> element is incomplete / has regressed in Safari 18 (through 18.5 ...

html.elements.del - Safari with VoiceOver does not announce text preceding `<del>` element · Issue #27443 · mdn/browser-compat-data

What type of issue is this? Incorrect support data. What information was incorrect, unhelpful, or incomplete? Support for the <del> element is incomplete / has regressed in Safari 18 (through 18.5 ...

github.com · GitHub

0
0
0
0
0
0
0
5
0
TheEvilSkeleton @TheEvilSkeleton@treehouse.systems
Public

Happy Disability Pride Month everybody :)

During the past few weeks, there's been an overwhelming amount of progress with accessibility on GNOME Calendar:

• Event widgets/popovers will convey to screen readers that they are toggle buttons. They will also convey of their states (whether they're pressed or not) and that they have a popover. (See !587)

• Calendar rows will convey to screen readers that they are check boxes, along with their states (whether they're checked or not). Additionally, they will no longer require a second press of a tab to get to the next row; one tab will be sufficient. (See !588)

• Month and year spin buttons are now capable of being interacted with using arrow up/down buttons. They will also convey to screen readers that they are spin buttons, along with their properties (current, minimum, and maximum values). The month spin button will also wrap, where going back a month from January will jump to December, and going to the next month from December will jump to January. (See !603)

• Events in the agenda view will convey to screen readers of their respective titles and descriptions. (See !606)

Accessibility on Calendar has progressed to the point where I believe it's safe to say that, as of GNOME 49, Calendar will be usable exclusively with a keyboard, without significant usability friction!

There's still a lot of work to be done in regards to screen readers, for example conveying time appropriately and event descriptions. But really, just 6 months ago, we went from having absolutely no idea where to even begin with accessibility in Calendar — which has been an ongoing issue for literally a decade — to having something workable exclusively with a keyboard and screen reader! :3

Huge thanks to @nekohayoJeff Fortin T. for coordinating the accessibility initiative, especially with keeping the accessibility meta issue updated; Georges Stavracas for single-handedly maintaining GNOME Calendar and reviewing all my merge requests; and @tyryluLukáš Tyrychtr for sharing feedback in regards to usability.

All my work so far has been unpaid and voluntary; hundreds of hours were put into developing and testing all the accessibility-related merge requests. I would really appreciate if you could spare a little bit of money to support my work, thank you 🩷

• ko-fi.com/theevilskeleton
• github.com/sponsors/TheEvilSke

(Boost appreciated)

Improve accessibility of GcalEventWidget (!587) · Merge requests · GNOME / gnome-calendar · GitLab

Calendar application for GNOME

gitlab.gnome.org · GitLab

TheEvilSkeleton @TheEvilSkeleton@treehouse.systems
Public

After two weeks of writing, revising, and trying to make everything as digestible as possible, I finally published "GNOME Calendar: A New Era of Accessibility Achieved in 90 Days", where I explain in detail the steps we took to turn GNOME Calendar from an app that was literally unusable with a keyboard and screen reader to an app that is (finally) accessible to keyboard and screen reader users as of GNOME 49!

tesk.page/2025/07/25/gnome-cal

GNOME Calendar: A New Era of Accessibility Achieved in 90 Days

There is no calendaring app that I love more than GNOME Calendar. The design is slick, it works extremely well, it is touchpad friendly, and best of all, the community around it is just full of wonderful developers, designers, and contributors worth collaborating with, especially with the recent community growth and engagement over the past few years. Georges Stavracas and Jeff Fortin Tam are some of the best maintainers I have ever worked with. I cannot express how thankful I am of Jeff’s underappreciated superhuman capabilities to voluntarily coordinate huge initiatives and issue trackers. One of Jeff’s many initiatives is gnome-calendar#1036: the accessibility initiative, which is a big and detailed list of issues related to accessibility. In my opinion, GNOME Calendar’s biggest problem was the lack of accessibility support, which made the app completely unusable for people exclusively using a keyboard, or people relying on assistive technologies. This article will explain in details about the fundamental issues that held back accessibility in GNOME Calendar since the very beginning of its existence (12 years at a minimum), the progress we have made with accessibility as well as our thought process in achieving it, and the now and future of accessibility in GNOME Calendar.

tesk.page · TheEvilSkeleton

Link author: TheEvilSkeleton@TheEvilSkeleton@treehouse.systems

0
0
0
0
0
0
René Dudfield @renedudfield@fosstodon.org
Public

I wish saved drafts of posts client side. Mobile web does not guarantee that a page will stay. Especially on lower end phones with lower memory, tabs go away. Which means thoughtful posts disappear, and people who take a while to gather their thoughts into words are disadvantaged.

Why just client side? Because most of the privacy issues are nonexistent. I expect a tiny snippet of JavaScript could be added as part of theme if main clients do not add it.

0
0
0
anelki @anelki@tilde.zone
Public

okay so things are ✨happening ✨!!

  1. Fun with : creating a plugin to enable better diagnostics, accessible remotely via an API to enable debugging.

  2. Improving OJS discussions, notifications, and editorial workflow. Provide more context to editors and make it easier for non-technical editors.

  3. Improving the experience for journals using open-review. Provide more gradients of control for how open-review works for each journal.

  4. Porting in further language/translation and accessibility improvements, especially for plugins

  5. Fixing/Updating Documentation: taking a more task based approach to how OJS/etc. works instead of making people read through a whole thing about the whole workflow for something.

  6. More documentation: integrating progress from previous sprints including for newly created plugins.

  7. (Unofficial) working on thinking about how integrating OJS into the fediverse might work (me, it's me, this is my fault)

@PublicKnowledgeProject

0
0
0
Gregory 🇨🇦 @gMoon@aus.social
Public

I’m looking for a job or a long-term contract working on websites or online customer service, remote or near Toronto, Canada. Many say I'm best for junior roles as I don't have many years of experience, however I'm open to almost any opportunity.

My specialties are: website developer, website performance, website accessibility, website consultant, and online customer service. I’m also open to other related roles.

I’m well known as someone who can fix or edit something on a website that others may not have the time or know how (especially WordPress, but I can work on other platforms).

Furthermore, I can work fully remote or in-person / hybrid near Toronto, Canada (I’m open to relocation within Canada). I have worked with people from around the world, I’m happy to adjust my schedule as needed.

I can work with any size company, including just yourself. Know of a one-off or short term project that you require help with (such as website evaluation)? I’m also open to those as well.

More details and my email address can be found at gregoryhammond.ca/hire-me/. My LinkedIn profile is at linkedin.com/in/hammondg.

Any referrals, links to job postings, or reposts are welcome (even if you aren’t affiliated with the company).

On a white background with someone holding a gray pencil, at the top in the centre are the words Gregory Hammond, and the website gregoryhammond.ca. A little bit down is five icons, starting from the left is a black and white globe, then a black and white computer screen and phone, then a circle with a green background and in the middle is a white outline of a pencil, next is a smaller blue circle with a white question, finally is a calendar with a number of different colours.

Hire Gregory

Gregory is available for hire or project-based work. He can work in-person anywhere in Canada or remotely. Need someone to work on your website, or customer service, contact Gregory Hammond today.

gregoryhammond.ca · Gregory Hammond

Link author: Gregory 🇨🇦@gMoon@aus.social

0
0
0
TheEvilSkeleton @TheEvilSkeleton@treehouse.systems
Public

Continuing our volunteer effort to make GNOME Calendar fully accessible with a keyboard (see thread for context), we fixed a major bug that was causing the focus to disappear into the abyss when the user tried to tab into the month view in merge request !576. This means, as of this commit, events should now be completely functional and accessible within the month view. Additionally, the merge request changes the keyboard and focus behavior within the month view: Events can only be cycled using arrow buttons, the focus can't escape the month view with arrow buttons, and entering/exiting the month view can only be done with tab. These improvements will be available on GNOME 49.

Improve accessibility with event widgets in the month view (!576) · Merge requests · GNOME / gnome-calendar · GitLab

Calendar application for GNOME

gitlab.gnome.org · GitLab

TheEvilSkeleton @TheEvilSkeleton@treehouse.systems
Public

Happy Disability Pride Month everybody :)

During the past few weeks, there's been an overwhelming amount of progress with accessibility on GNOME Calendar:

• Event widgets/popovers will convey to screen readers that they are toggle buttons. They will also convey of their states (whether they're pressed or not) and that they have a popover. (See !587)

• Calendar rows will convey to screen readers that they are check boxes, along with their states (whether they're checked or not). Additionally, they will no longer require a second press of a tab to get to the next row; one tab will be sufficient. (See !588)

• Month and year spin buttons are now capable of being interacted with using arrow up/down buttons. They will also convey to screen readers that they are spin buttons, along with their properties (current, minimum, and maximum values). The month spin button will also wrap, where going back a month from January will jump to December, and going to the next month from December will jump to January. (See !603)

• Events in the agenda view will convey to screen readers of their respective titles and descriptions. (See !606)

Accessibility on Calendar has progressed to the point where I believe it's safe to say that, as of GNOME 49, Calendar will be usable exclusively with a keyboard, without significant usability friction!

There's still a lot of work to be done in regards to screen readers, for example conveying time appropriately and event descriptions. But really, just 6 months ago, we went from having absolutely no idea where to even begin with accessibility in Calendar — which has been an ongoing issue for literally a decade — to having something workable exclusively with a keyboard and screen reader! :3

Huge thanks to @nekohayoJeff Fortin T. for coordinating the accessibility initiative, especially with keeping the accessibility meta issue updated; Georges Stavracas for single-handedly maintaining GNOME Calendar and reviewing all my merge requests; and @tyryluLukáš Tyrychtr for sharing feedback in regards to usability.

All my work so far has been unpaid and voluntary; hundreds of hours were put into developing and testing all the accessibility-related merge requests. I would really appreciate if you could spare a little bit of money to support my work, thank you 🩷

• ko-fi.com/theevilskeleton
• github.com/sponsors/TheEvilSke

(Boost appreciated)

Improve accessibility of GcalEventWidget (!587) · Merge requests · GNOME / gnome-calendar · GitLab

Calendar application for GNOME

gitlab.gnome.org · GitLab

0
0
0
TheEvilSkeleton @TheEvilSkeleton@treehouse.systems
Public

As part of our volunteer-driven accessibility initiative in GNOME Calendar, and for the first time in the 10+ years of Calendar's existence, we finally completed and merged the first step needed to have a working calendar app for people who rely on keyboard navigation. This merge request in particular makes the event widgets focusable with navigation keys (arrow left/up/right/down) and activatable with space/enter. This will be available in GNOME 49.

Most of GNOME Calendar's layout and widgets consist of custom widgets and complex calculations, both independently and according to other factors (window size, height and width of each cell, number of events, positioning, etc.), so these widgets need to be minimal to have as little overhead as possible. This means that these widgets also need to have the necessary accessibility features reimplemented or even rethought, including and starting with the event widgets.

We also hope to get other parts of GNOME Calendar accessible before GNOME 49, but I can't promise anything at the moment. We did start working with making the month view accessible: gitlab.gnome.org/GNOME/gnome-c

Make the event widget accessible (!559) · Merge requests · GNOME / gnome-calendar · GitLab

This implements button functionality to make it able to focus and activate it. This also sets the appropriate accessibility role and labels/descriptions. Related:

gitlab.gnome.org · GitLab

TheEvilSkeleton @TheEvilSkeleton@treehouse.systems
Public

Continuing our volunteer effort to make GNOME Calendar fully accessible with a keyboard (see thread for context), we fixed a major bug that was causing the focus to disappear into the abyss when the user tried to tab into the month view in merge request !576. This means, as of this commit, events should now be completely functional and accessible within the month view. Additionally, the merge request changes the keyboard and focus behavior within the month view: Events can only be cycled using arrow buttons, the focus can't escape the month view with arrow buttons, and entering/exiting the month view can only be done with tab. These improvements will be available on GNOME 49.

Improve accessibility with event widgets in the month view (!576) · Merge requests · GNOME / gnome-calendar · GitLab

Calendar application for GNOME

gitlab.gnome.org · GitLab

0
0
0
0
0
0
0
0
0
dallo @dallo@pouet.chapril.org
Public

It’s True, “We” Don’t Care About Accessibility on Linux

tesk.page/2025/06/18/its-true-

It’s True, “We” Don’t Care About Accessibility on Linux

What do virtue-signalers and privileged people without disabilities sharing content about accessibility on Linux being trash have in common? They don’t actually really care about the group they’re defending; they just exploit these victims’ unfortunate situation to fuel hate against groups and projects actually trying to make the world a better place. I never thought I’d be this upset to a point I’d be writing an article about something this sensitive with a clickbait-y title. It’s simultaneously demotivating, unproductive, and infuriating. I’m here writing this post fully knowing that I could have been working on accessibility in GNOME, but really, I’m so tired of having my mood ruined because of privileged people spending at most 5 minutes to write erroneous posts and then pretending to be oblivious when confronted while it takes us 5 months of unpaid work to get a quarter of recognition, let alone acknowledgment, without accounting for the time “wasted” addressing these accusations.

tesk.page · TheEvilSkeleton

0
0
0