13 Jan 2019
When developing AlwaysInMind I made the concious decision to use React but avoided the more sophisticated and opinionated Nextjs. I generally feel it is better to use minimal dependencies and develop your own abstractions according to the problem at hand. This is especially true when you are learning both the technology and the application architecture as you explore your problem domain. I find this working “bottom up” approach to be much more productive and less frustrating than starting with a highly opinionated framework such as Angular. YMMV :)
I finally decided on Create React App (CRA) as providing a good starting point that neatly manages the dev and build configuration yet allows much flexibility in architectural style. This proved to be an excellent choice as I was able to concentrate on my application artefacts without CRA getting in the way.
AlwaysInMind evolved into a rich React SPA coupled with a NodeJS + Ziet micro powered API server that provides a facade to various 3rd party SaaS APIs including Auth0, Google Photos and YouTube. This is a minor variation of the so called ‘JAMstack’ architecture which in many cases provides an excellent developer experience and scalability.
Recently, NextJS added a static export option that can provide a JAMstack like architecture. But to be honest it is backwards in approach. It takes a full SRR design and scans all the links in an attempt to determine a correct set of static files. That is pretty fragile and anyway, it is a post process to designing in an environment that is all about SSR and so likely to lead to decisions that don’t map well.
Two features stand out when analysing what Next offers when exporting to static. The first is the ability to put SPA page components in a folder and have routes automatically provided. This is minor but still useful convenience and in fact it’s fairly common to want explicitly declared dynamic child routes of an automatically mapped page.
The other useful feature is the provision of a consistent model for asynchronous data fetching in pages using getInitialProps(). Actually, a JAMStack app is likely to collect data from many sources. More importantly, some of the data can be determined at build time, not left till run time. This could be static data or data fetched from a remote service.
While these features are relatively easy to develop I recently discovered the light weight React Static framework. This has a nice clean approach to data provision, separating out the build time determined data into a single configuration file and injecting it page properties. Doing this helps clarify thinking about where and when data is captured, leading to a better UX. As for pages, they can be automatically or explicitly routed as required.
With a few Core Concepts, React Static has very few opinions on top of basic ReactJS. The source code is clean which is an advantage for such young, sole-developer project. Having said that, Tanner Linsley, the developer, is friendly and responsive.
I’m looking forward to exploring React Static for my new project. So far so good.
04 Jan 2019
The W3C Cognitive Accessibility Task Force have captured a mass of knowledge and experience on the cognitive requirments and barriers that people often experience when using web tchnology. This appears in several published W3C Technical Recommendations (TRs), unpublished Editors Drafts and a set of Issues on GitHub. There is also the team wiki. Most of these documents are large, with much detail.
For many, this mass of information is dense and a little hard to digest. Examples of people looking to learn from these documents include; those new to coga concepts, developers looking for design guidance or specification authors working to support more coga requirements.
The Task Force members therefore felt a desire to provide easier access in the form of introductory signposting and way-marking pages.
The relatively new WAI Website is designed to provide easy access to the broad WAI guidance and resources. It does an excellent job of this and so makes an ideal place to put any new coga pages. These new introductory pages can then link to the published TR documents, providing selected paths into the large coga content set.
Thus, my 1st contribution as a W3C staff member is a crude mockup of how a set of pages could look when added to the WAI website. These pages are a real hack but do show the structure along with enough content to make the conepts clearer.
Here are the mockup pages
As always, the coga TF would welcome thoughts and ideas from new members.
11 Nov 2018
Back in August I spotted Shadi’s announcement looking for a Cognitive Accessibility Specialist to join the W3C WAI staff. Having been involved with the work of the Cognitive Accessibility and Learning Disabilities Task Force I had become aware of the many complexities in supporting people with these “hidden disabilities” in the W3C Web Content Accessibility Guidelines (WCAG) and beyond.
The job of clearly describing cognitive preferences and then formulating suitable conformance measurements for WCAG is complex and nuanced. Cognitive requirements are often less easy to relate to than say those for visually impaired people. They commonly vary widely between individuals in both degree and combination. Defining such variable user requirements and mapping them to distinctly measurable technical features is difficult. It is also an immature science with little published research or practical experience available. Despite this, Lisa and the Task Force have done an amazing job and generated several comprehensive documents. But, there is still so much more to do before everyone who uses WCAG to inform their design and development activities will be usefully addressing cognitive preferences.
So I decided to email Shadi and Judy at the WAI, thanking them for the decision to dedicate core staff resource to help support this important work. Strangely, as I typed, I found myself realising I’d love to be “that person”. I saw a clear opportunity to widely help improve people’s experience of technology, via the standards that are used by companies, governments and others to ensure accessibility of their websites and other user facing technologies. For me, this is a change in approach from developing a cognitive AT product, AlwaysInMind, but possibly more suited to my skills and background.
Long story short, I ended up applying for the post and after various bumps in the road (including the unwelcome uncertainties caused by the looming BREXIT) I have now just finished my 3rd week as part of the W3C WAI team, employed by ERCIM in France. The exact details of my role will emerge in time but in essence I’ll be working to improve the coga11y story. This will involve fairly horizontal activity around coga, WCAG, Personalisation and the EU 2020 Easy Reading project of which W3C WAI are consortium members.
My 1st experience was incredible! While the ink was still wet on the contract, I rushed over to the annual W3C TPAC meeting in Lyon, France. In 5 days I managed to meet many of the dedicated folks working on WAI standards and guidelines through their activity in workgroups and taskforces. A handful were old friends, some going back to the time I started serious accessibility work on GNOME, Mozilla Firefox and the IAccessible2 platform API for Windows. Many others, I have met since, either on line or at various conferences. A few I have followed and respected from a distance until getting the chance to meet them at TPAC. Such an inspiring group.
I found myself playing WAI “Bingo” and managed to get a full house of the various accessibility groups; AG, APA, EO, ARIA, Coga, Personalisation, ACT and others. It was a whirlwind of meeting welcoming people while absorbing organisational and procedural details of W3C and WAI. Phew!
The next 2 weeks back home have been and intense but enjoyable period of on-boarding. The usual medley of meeting people, attending working group meetings, learning my way around the intranet, plus installing and configuring tools.
Perhaps most important has been becoming familiar with the relevant publications. There’s only around 10 key documents to internalise but considering WCAG is not alone in it’s size and density I’m going to be very busy over the next 3 weeks! :)
I’m so happy to be a part of WAI and very much look forward to contributing to the Coga11y support of WCAG and wider.
13 Oct 2018
The EU funded FP7 project Prosperity4All successfully completed, providing several components of the GPII. I delivered documents and code providing a ‘Stepping stones’ framework for applications designed for people cognitive disabilities and low digital literacy. A set of components were added to the GPII Developer Space.
My main focus has been bootstrapping the AlwaysInMind product and open source platform for easy access to media and communications for people with cognitive disabilities. Having developed the prototype we’re now looking for partners to help with user validation and business.
AlwaysInMind was a finalist in the Ability Net tech4good awards. We did not win but it was fantastic to meet so many dedicated and inspiration people, including presenter Kate Russell.
Resumed as an invited expert on the W3C Cognitive and Learning Disabilities Accessibility Task Force led by Lisa Seeman.
I worked with the lovely NeonTribe in Exeter, developing a cognitive accessibility related prototype using ReactJS. I was also introduced to the Mind of My Own MOMO tech4good project team.
Became an early adopter of the Azure Functions serverless platform having met the team at the Serverless conference London. We created a website / blog and Twitter ID AzureServerless. Eventually decided to ramp this down and passed the accounts over to the Azure team for their use.
Explored a range of interesting technologies for developing accessible web apps and PWAs, mainly with with nodejs back ends. The following are highly recommended:
React, redux and Next frontend libraries. Create-react-app is invaluable.
hyperapp a very pleasant micro framework including VDOM and state management in a tiny file.
The much anticipated CSS Grid and Firefox Grid explorer in F12 tools
TypeScript, ESLint and Prettier for static code validation
Cypress.io end-to-end testing that is a joy to use.
Microsoft Azure Functions and Logic Apps serverless features.
Zeit now incredibly easy to use serverless tooling. So innovative. Just awesome.
Zeit micro and serve for light back end on node.
Microsoft Azure DevOps Services (was VSTS) CI/CD for anything and more, including free git repos.
17 Sep 2018
Steve’s old Opening Accessibility” WordPress blog has been archived here. It was converted to static HTML using the “simply static” plugin.
Our Azure Serverless site about Azure Functions WordPress site is also archived here.