pickpuck

ExplorerPatcher fixes everything I hate about Win11

This adage has been "the first rule of ARIA" since the beginning.

There are a few ARIA "widgets" that have no HTML equivalent, such as Tabs or a spreadsheet-like Grid. Those are heavily documented so you can basically copy and paste whenever you need them.

Avoiding sprinkling ARIA on already-semantic HTML, because this can lead to confusing or inconsistent behaviors for the end user.

They're working on it in the "Core Accessibility API Mappings" spec

https://www.w3.org/TR/core-aam-1.2/

Location: Louisville, KY, USA (EST)

Remote: Yes

Willing to relocate: No

Technologies: TypeScript, React, React Native, Next.js, Node.js, TailwindCSS, AI/LLM integration, UI/UX, Figma, Design systems, WCAG accessibility, Lit.js, Web components

Résumé/CV: https://puckett.codes

Email: michael@puckett.contact

I'm a creative technologist with extensive experience building accessible, user-friendly digital products and tools. X-Apple. X-Google. 15+ years in tech.

Open to freelance work, employment, co-founder roles.

The joy of US "at-will" employment is that every company's Code of Conduct reserves the right to "separate" you for undermining mission alignment. The whole system is toxic.

What if we extended this idea beyond one dataset to all discrete news events and entities: people, organizations, places.

Just like here you could get a timeline of key events, a graph of connected entities, links to original documents.

Newsrooms might already do this internally idk.

This code might work as a foundation. I love that it's RDF.

I built something with Service Workers a few years ago. It's similar in concept, but I never got around to syncing with a server.

Instead of a WASM backend, I used react-dom/server to generate the HTML.

https://github.com/michaelcpuckett/listleap?tab=readme-ov-fi...

Neat, is it on github?

building a more AI friendly DOM

You might consider the Accessibility Tree and its semantics. Plain divs are basically filtered out so you're left with interactive objects and some structural/layout cues.

This is a cool idea! At first I thought it was that they give you notes about what happened, and you have to process the information real-time and suggest practical improvements.

If you're searching for a physical reference guide, I'd imagine "Word Clues" from middle school still holds up.

https://www.goodreads.com/book/show/1616203.Word_Clues_Vocab...

Can you link to the ATS checker please?

Does it implement the proposed Declarative Custom Element spec with slice templating?

https://github.com/EPA-WG/custom-element

They do pick up the "title" attribute sometimes and apply it as a label. But it's not really the same as being able to keyboard navigate to the browser-generated tooltip.

This link 404s because it should be www instead of wwww

Location: Louisville, KY, USA

Remote: Yes

Willing to relocate: No

Technologies: TypeScript, JavaScript, HTML, CSS, React, Vue, Lit, Svelte, etc.

Résumé/CV: https://michaelpuckett.engineer

Email: michael@puckett.contact

LinkedIn: https://www.linkedin.com/in/michaelcpuckett

Ex-Apple. Ex-Google. Creative technologist with extensive experience building for the web platform. Focused on crafting accessible, user-friendly digital products and tools.

https://archive.is/pfSAD

Check out these syllabi/ebooks, lots of focus on history of UI/UX and foundational patterns:

https://faculty.washington.edu/ajko/books/user-interface-sof...

http://faculty.washington.edu/ajko/books/foundations-of-info...

https://github.com/peterw/Chat-with-Github-Repo

For instance, the Esc key does not close non-modal dialogs by default

Modal dialogs are the ones that pop up on the screen and take over the main experience. Those come with escape key. I think you have to program the click-away with JavaScript however.

Non-modal dialogs are uncommon, but basically they are more like menu pop-ups that can be ignored when open, so no need for escape key.

Interesting! I'd say:

<font> provides no structural or accessibility information. It was only there for styling purposes.

<dialog> provides structural and accessibility information plus interactivity that previously required JavaScript. It comes with default styles but that's not the primary reason to use it.

Cool idea! I'll start looking into that.

I think this refers to handling JSON ActivityStreams objects at the `/outbox` endpoint for a logged-in user, and then broadcasting those out appropriately. If so, then yes that's the only API that's used. It also handles the uploadMedia endpoint and a few other details that are included in the spec.

I have tried unsuccessfully so far to set up an OAuth provider server along with it, so that you could log in on your phone, etc.

Ahh this is so exciting to see so much happening in this space all of a sudden! My quest to get a personal instance running has been a long slog for me personally.

I had been working on an ActivityPub server in Node.js/TypeScript for a while before the Twitter migration. It's got most of the features I'd want in a small server but it's basically bring-your-own-client at the moment.

https://github.com/michaelcpuckett/activitypub-core

Finding all the resources to build a complete server that can interact with other instances isn't easy, so maybe this can help someone. The spec is well worded, but the checklist is confusing, the test server is down, Mastodon has its own rules, etc. Plus you have to have at least a cursory knowledge of JSON-LD/RDF.

Here's a list of developer tools that might be helpful:

https://codeberg.org/fediverse/delightful-activitypub-develo...

including unproductive meetings

That would certainly tip the scale.

I think this demonstrates that:

1) the hit area of native checkboxes should be larger, and

2) fieldsets with checkboxes should come with a native "Toggle All" button

They should be making their website’s code more accessible to legacy devices.

If there's an iota more work involved, the analysts have no reason not to defer to analytics. Anything less than ~1% gets dropped. So there goes your ES5 build.

"Accessibility" in the screen reader sense is additional work done to support a low-usage audience, but because it has legal implications it has much more weight.

I guess it would take someone using older tech winning in court for this to be given greater consideration. But that seems unlikely because people who use older tech are not a protected class.

Yes!

Here it is:

https://dnnlv5ifs.blob.core.windows.net/portals/2/DB/Images/...

I would recommend getting comfortable using the built-in screen readers on your own devices (VoiceOver, Narrator, etc). Lots of people use those same tools. You'll probably just want to mute the screen reader and use the developer option to display what's being announced on screen as text.

Get comfortable navigating web pages using the various functionalities available (the ability to scan only headlines, for example).

I also open the accessibility tab in the web inspector in Chrome or Firefox to see the accessibility tree, which is like a simplified version of the DOM tree that gets exposed to assistive technologies.