search

datakurre / robotframework-wavelibrary

Accessibility validation library for Robot Framework based on WAVE Toolbar by WebAIM
9 stars 4 forks source link

Updating this for the xpi era? #3

Open bollwyvl opened 3 years ago

bollwyvl commented 3 years ago

Thanks for this! XUL is dead, long live XPI :sob:

Any interest in warming this back up? Things are a little better/worse now:

I'd consider pyautogui, but despite its awesomeness, has a lot of limitations... primary among them being no access to headless browsers.

The approach you took here, of having a custom extension, would probably be able to use the blessed JS APIs to trigger one of those above without resorting to screen calculations, but might need a developer edition firefox (which i don't have handily packaged) to be side-loaded unsigned.

datakurre commented 3 years ago

I actually got a chance to try out pyautogui + opencv + xvfb already https://rpa.pages.kopla.jyu.fi/wavebot/

datakurre commented 3 years ago

But in short, yes. I should look into if I could merge my local changes here. I did use install_addon until I was requested to change to Chrome. I also did find all those Selenium limitations. Fight against web extension security is futile, even with a custom extension.

The good part is that in the current WAVE releases, reading the results are easy.

So, I should be able to fix this library with pyautogui and optionally opencv. The extension would ship some example images for activating the extensions on some Linux distribution, but would have support for reading the paths (path for extension and path for image template for activating the extension) from either arguments or from configuration values. Hopefully with a github action example

bollwyvl commented 3 years ago

requested to change to Chrome.

Oh, man, what a mess chrome testing is these days. I'm having to lean really hard on docker, etc. to keep up with chrome(driver) churn and don't even bother for open source stuff... all the other newfangled approaches, on the other hand, drive me crazy, as they aren't the Real Thing.

Fight against web extension security is futile

Yup, as the borg say, Ω is futile...

reading the results are easy.

Yeah, it looks good! Yanking the results into something that can be looked at over time is important indeed, whether its JSON, or embedded within a robot/xunit log.

Hopefully with a github action example

You know I'm exhausted by CI provider churn, but GHA has actually been quite good. Despite myself, I even like the typescript-based stuff, as you're pretty close to the guts of the first party stuff, which can't be said for a lot of other providers. I do miss having a no-fuss HTTP deployment target for artifacts, e.g. Circle, Jenkins.

I do wonder what an "all-in-one" robot action would look like, but fear that the amount of knobs it would need would be overwhelming, to say nothing of installing stuff like xvfb. A focused one on accessibility testing, however, could be quite reasonable, as you'd be less concerned about coverage across environments and just Assess The Artifact.

Anyhow, happy to help! In the meantime, i'm looking into firming up the pyautogui stack for my purposes (conda, etc)... all for clicking that one button. Sigh.

bollwyvl commented 3 years ago

My goal here, as you no doubt would imagine, would be to be able to take this as a dependency for robotframework-jupyterlibary... there is a fair amount of effort going on to improve the systemic neglect for different abilities and perspectives (both accessibility and internationalization) in that community. Automation is no substitute for empathy and thoughtfulness, of course, but as a broad community, primarily linked by code, packages, and CI, doing the most we possibly can with those media would at least establish a baseline. Probably the most crushing piece is CodeMirror5, so maybe this will spark a more serious look at adopting CM6, but I'd much rather have some reproducible data that shows, look, this reduces the number of glaringly obvious problems by X.

datakurre commented 3 years ago

I guess, it would be possible to extract the analysing code from WAVE to make it easy to automate, but I am not sure about their licenses and for sure it would be unmaintainable. Therefore I’d prefer to being able to just use the official WAVE release and not bundle it anymore (we did had some kind of vague permission to bundle this previously...). On 8. Dec 2020, 16.13 +0200, Nicholas Bollweg notifications@github.com, wrote:

My goal here, as you no doubt would imagine, would be to be able to take this as a dependency for robotframework-jupyterlibary... there is a fair amount of effort going on to improve the systemic neglect for different abilities and perspectives (both accessibility and internationalization) in that community. Automation is no substitute for empathy and thoughtfulness, of course, but as a broad community, primarily linked by code, packages, and CI, doing the most we possibly can with those media would at least establish a baseline. Probably the most crushing piece is CodeMirror5, so maybe this will spark a more serious look at adopting CM6, but I'd much rather have some reproducible data that shows, look, this reduces the number of glaringly obvious problems by X. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

bollwyvl commented 3 years ago

Oh let's not get in any trouble! My thought was to distribute the URL to the moz cdn, so we could test against a known point, but let the keyword override it... Heck it could even visit the store to find the latest url.

Another approach: maybe we can use https://github.com/mozilla/web-ext (gaaah nodejs) to manage the browser lifecycle with a custom loaded extension, and somehow inject stuff into it? Seems more fragile then pyautogui, somehow, but is at least first-party... At least that we could probably bundle down to a single js file with ncc or equivalent...