WestonThayer

If you want to probe what encodings a VNC server supports, here's a rudimentory method. Run the below script (following the notes), subbing out the first encoding you pass in the array.

If it's not supported, you'll see an encoding log of 0 (the server fell back to raw). Otherwise you'll see the encoding you specified (or an error from rfb2 because it doesn't know how to deal with it, but that's fine).

https://chatgpt.com/share/692dfd34-f3ec-8013-a45a-4abb5506964c has some thoughts on "desirable" protocols. My sense is that ZRLE is the most modern standard for lossless. Tight might be a faster lossy alternative. H264 is probably awesome, but good luck finding a VNC server that supports it.

const rfb = require("rfb2");

// MODIFY: rfb2/rfbclient.js readFbUpdate() to log the rect.encoding when received

WestonThayer

If you need to test with WinRM in a very basic way....

On both the client and server, run winrm quickconfig. Use Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private if necessary to get clean results.

Then on the server, run winrm set winrm/config/service/auth '@{Basic="true"}' to allow very basic auth. Make sure the current server user has a password.

On the client, use Set-Item WSMan:\localhost\Client\TrustedHosts -Value IP -Force.

Then make sure, if the server is behind a firewall, that TCP 5986-5986 is allowed through.

WestonThayer

// Drop in https://unpkg.com/axe-core in console, then...

(await window.axe.run()).passes.find(p => p.id === "color-contrast").nodes.forEach(n => n.target.forEach(t => document.querySelector(t).style.backgroundColor = "pink"))

WestonThayer

Follow along at https://assistivlabs.com/articles/automating-screen-readers-for-accessibility-testing

Requirements

• A Windows PC (or virtual machine)
• Node.js

Instructions

1. Download this Gist as a zip on Windows

WestonThayer

// https://github.com/microsoft/playwright/issues/27130

/**
 * Turn a single string character into KeyboardEvent.code and whether a Shift
 * modifier is required.
 *
 * I have no idea how this works if your local keyboard layout isn't US.
 *
 * @param {string} char
 *

WestonThayer

name: test
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: windows-latest
    steps:
      - run: "& 'C:\\Windows\\Resources\\Ease of Access Themes\\hc1.theme'"
      # Will upload an artifact to the run with a desktop screenshot

WestonThayer

<button aria-pressed="false">
   <span aria-hidden>13</span>
   <span class="visually-hidden">
     13 December
  </span>
</button>
<!-- Read as "13 13 December" -->

WestonThayer

x-height test while zooming

A basic algorithm to check if any given webpage has "accessible" text scaling, based on https://github.com/w3c/silver/issues/506#issuecomment-817045025, which approximates x-height as ~50% of font-size (so the min and max x-height sizes from user research have been 2x'd):

• All text can reach a rendered font-size of least ~88 CSS px
• No text exceeds a rendered font-size of ~120 CSS px

By "rendered font-size", I mean the computed CSS font-size value multiplied by the current zoom level (100%, 150%, etc). So for example, assuming linear scaling, 17.6px would be the minimum acceptable size because browsers have a max zoom of 500% and 17.6 * 5 = 88.

1. Start at some "desktop" viewport, say 1280px wide, and 100% zoom

WestonThayer

Twitter thread for context: https://twitter.com/__grunet/status/1434197313795330049

Q: Is it possible to run the Android Emulator in the cloud?

A: Yes, either in a bare metal cloud or with nested virtualization.

Q: Is it easy to set up?

A: Sort of, I'm sure a lot of it could be scripted. https://github.com/budtmo/docker-android has put a lot of work into making it fast once you have a Linux machine ready (I didn't test it). With nested virtualization, you could do these steps once and take a VM image.

WestonThayer

// Browsers keep track of where your keyboard focus is when you click
// a link, and they restore focus to the same link when you navigate
// back (via https://web.dev/bfcache/)
//
// SPAs like Next.js break this paradigm because they handle routing
// themselves. This is a basic approach bringing the feature back. It
// doesn't handle restoring the view-state (well, Next.js handles
// scroll restoration out-of-the-box, but that's it) like re-opening
// dropdowns or dialogs or FAQ items that contained the clicked link.