In case you missed it, I sat on a panel with five other accessibility experts on December 13, 2022 at 8 AM AKST. Panelists included Adrián Bolonio, Albert Kim, Beatriz González Mellídez, Shruti Kapoor, and Crystal Preston-Watson.
After overcoming a few technical difficulties, we got on a roll chatting with This Dot folks to discuss:
the current state of digital accessibility in 2022,
trends and barriers we encountered as those working in the field of accessibility, and
some of our own personal experiences as temporarily, situationally, or permanently disabled.
You can watch the recorded video on YouTube, which runs a little over an hour. A live captioner was present, but captions are included inside the video (not the video player). Hopefully, customizable captions and downloadable transcript will be available soon.
I offered only a few visuals to help visual people see the barriers I encounter on my laptop and smartphone. Here are the screenshots I used, in order of my talk:
For questions about my talk, you can contact me or find me online at:
HTML’s output element is pretty amazing. I mean, honestly, HTML is pretty amazing, right? Many elements can just DO things, plus express their own purpose. The output‘s abilities are no less astounding. Think about. You put in some value, and there they are on the screen. To me, it’s like magic.
The MDN (Mozilla Developer Network) defines it as:
The <output> HTML element is a container element into which a site or app can inject the results of a calculation or the outcome of a user action.
Oversimplified? Dynamic information results display here.
It’s usually coupled with an input inside a form. A user can enter information into the input field and see a live calculation or result in the output container. The result can happen as data changes or the user activates a submit button. Sometimes the result can come from another source, but it still needs user guidance to receive that result.
Two examples of output in action
Example 1: Markdown Previewer
Someone can enter markdown in an expandable text box and see the HTML-structured content appear in the output container (previewer).
Example 2: Multiplication Table
Someone can enter a positive number between 1-12 to create it’s multiplication table.
Note on accessibility
Considering accessibility is always my main focus in web development, I’d be remiss to ignore that detail when choosing to use the output element.
In their HTML documentation, MDN mentions:
Many browsers implement this element as an aria-live region. Assistive technology will thereby announce the results of UI interactions posted inside it without requiring that focus is switched away from the controls that produce those results.
In both of my examples, an aria-live region may or may not be the right choice. After creating these examples, I had several questions, in which I could only speculate the answers. Fortunately, I found some of my answers through Scott O’Hara’s accessibility testing of the output element!
In my first CodePen example, I was torn about using output. Should I even consider changing focus to output? That just feels rude (and evil) while someone is still typing. Should I make output focusable with tabindex=0? Additionally, I learned through Scott’s article that headings and lists aren’t allowed, so I question if I should abandon output as a solution for my markdown viewer altogether. It seems like I’m just asking to break an accessible experience. To quote Scott, “Concise, simply marked up messages are key for well performing live regions. Think of these restrictions as guardrails to keep your content understandable and accessible!”
In my second scenario, I added a submit button, so the results would appear when the user was ready. I felt that oninput can create a surprising, overwhelming, or frustrating experience if the person hasn’t finished typing.
Through my own light and lazy testing, I noticed that announced updates in the previewer weren’t consistent between Firefox/VoiceOver/macOS and Safari/VoiceOver/iOS. I could test further, but deeply feel that the implementation of output deserves solid AT (assistive technology) user testing to learn from what they expect and how it affects them. I’d love to see that documented somewhere!
Note on JavaScript
Ok, ok, so I did say at the beginning that HTML is like magic because some elements just DO things. The output element does need some JavaScript (and CSS) to help it along. Often, that JavaScript is inline with the element itself.
To start, you should use the attributes it comes with (for, id, name). In my examples, I started with output’s attributes and the form’s event handler. After I had those key pieces set up, I started adding additional JavaScript. My second example with the array needed a separate JavaScript function to calculate that.
As a side note, related more to CSS, I was happy to discover how easily I could style the output element.
When should I use output?
Just like any HTML element, output was created for a very specific purpose. It’s useful in instances when your user needs to enter information and receive immediate results on that page. A few examples where I think it could be useful:
financial aid calculator
file download or upload progress
shopping cart product add-ons
What motivated me
I learn through building. Videos and blog posts are wonderful resources. But until I can apply the information I’ve consumed, I can’t get that information to stick.
This exploration of output is brought to you in part by freecodecamp and CodeWars. Recently, I’ve been working through a few front-end projects and JS katas. Those got the wheels in my head turning. My curiosity was peaked and I had to try a couple things.
I don’t claim to have made perfect examples of the use of the output element. Not to mention I could spend a lot more time on styling and usability. But I did discover a lot in the process!
I hope my learning encourages you to give this underrated HTML element a try, too. You might just find it’s useful in your next project in place of a div.
On February 2, 2022 I gave an intro to accessibility talk for Buddy. It was fun having the chance to encourage more people to make their website accessible.
Video runs 1 hour and 17 minutes.
I’ve been assured professional captions and transcripts will be available soon.
On March 29, 2021, I gave a live coding demonstration alongside other accessibility experts Nic Steenhout and Eeva-Jonna Panula. I shared about poor component development I’d encountered in a recent project I’ve worked in, and the efforts it took me to remediate those accessibility problems.
Caption are are available, but React Finland leaned on YouTube autocaptions, so there are mistakes in the captioning. Update 4/12/2021: React Finland has updated their captions.
Mayday! For two days I’d been trying to solve a mystery for a client that I’ve been guiding in PDF accessibility. We knew that InDesign was causing the issue, but we struggled to figure out how the issue was being caused.
Let me back up a little to offer some context. My client creates things in Adobe InDesign. She exports them to PDF, then runs each PDF through a few accessibility checkers, including PAC3. PAC3 was the wall we kept hitting. Specifically, the error said “Path object not tagged”. I easily found the trouble: several Path objects, each cell border of each table in the document, were not nested inside containers within the Content panel.
PAC3 report insists there are failures.
For a quick fix, I showed her that she could select each Path object, right-click, and create an artifact. However, that technique was laborious, and we both wanted to fix the error at the source (InDesign).
Selecting all the Path objects… so tedious.
What I couldn’t understand was why those “decorative” objects were coming over without being recognized as artifacts. Things I tried:
digging around the InDesign template,
checked paragraph and character styles,
checked if each table was a true table,
created table styles from scratch,
messed with tagging,
deleted and re-added objects into the Articles pane.
All to no avail! After conversion to PDF, we still kept receiving the same 533 errors.
It was time to call for backup. I started tapping into the accessibility community via Twitter and Slack. Funny enough, I mentioned to one of my friends over text that I was struggling with this document and she immediately connected me with an accessibility document specialist she’d just met after attending a PDF accessibility webinar that day. Whoa! He quickly responded and jumped on a Zoom call with me to work it out. Turns out, it was an easy fix (literally).
He confirmed that it’s another vice we have to accept with InDesign when creating tables. Those table border paths just don’t get put into artifact containers, as seen in the Content pane. The good news is that you can have Adobe Acrobat fix it for you. Add this Preflight fix to your list of other things you have to do to pass PAC3’s tests and meet PDF standards:
Open the Tools panel.
Open the Print Production tool.
Select Preflight.
Ensure PDF Standards is selected in the first dropdown menu.
in the Profiles tab, search “artifact”.
Under the Document accordion.
Select “Mark all non-structure elements as artifact” option.
Activate the Fix button.
Done!
Preflight to the rescue!
Huge shoutout to Dax Castro, who took 15 minutes to solve my mystery and answer other quirky PDF questions I had. The accessibility community has been amazing at welcoming me in, teaching me new things, and encouraging me to keep going. Thank you, all!
Recently I had a conversation with an accessibility colleague at work about accessibility overlays for webpages. This conversation sprouted from a goal set a couple years ago that aimed to explore options and purchase a 3rd-party overlay for our sites as a solution to improve the accessibility of our web presence. Thankfully, time passed with no action, and I’ve solidified my own opinion that overlays are not a good solution.
Though technology provides us with a lot of amazing automated things, I still believe web accessibility should be a mostly hands-on process. We can lean on automated tools to scan and audit our site, giving us a general idea and visualization that problems exist. However, nothing beats a real person testing a website if it’s accessible and usable.
So, after I re-discovered a few articles by experts I follow online, and emailed my professional opinion to my colleague, I thought it would be great to share my round-up with a wider audience, in case someone else needs a quick defense to copy and paste into an email before their organization falls for the trap of this “miracle” widget.
My defense
7 reasons why accessibility overlays aren’t a magical solution? Because add-ons…
Often haven’t been verified to work well, if at all.
Don’t actually fix bad code or design.
Put the burden on users to learn your site tool rather than just using their assistive tech or adaptive strategies.
May even conflict with the visitor’s assistive tech or customizations they use on their computer/phone.
Give a web development team a false sense of security, rather than encouraging them to learn valuable accessibility skills; it delays the inevitable that fixes need to be made.
Only “solves” accessibility on your website; it doesn’t create a usable experience throughout the web as visitors travel between sites.
May compromise your site’s performance and security due to the injection of code from a 3rd party vendor.
Note: There are more reasons that can be used, but seven reasons were enough to make my case, and could easily be identified in the resources I provided.
My solution
After sharing my reasons, I offered my advice:
“I propose we strike this item from our list of goals and focus on things that will strengthen our sites, skillset, and overall accessibility culture. It’d be a shame to put a lot of money into an overlay tool and still get sued (costing us more money and time). Let’s put that money and time toward our staff and just fix (or delete) our stuff.”
Eloquent? Maybe not.
Direct? Definitely.
I whole-heartedly believe in developing a culture of accessibility, learning the “hard” stuff, and putting one foot in front of the other to get the work done. If we continue to waste time with automating all the things and avoiding the redesign of our services to do better, then we’ll never actually have a more accessible web. Let’s do better and keep learning.
Naturally, after I sent off my email, posted a thread on Twitter, and started this post, I heard about another article published the same day that also had 7 points to make about why overlays are a bad idea:
It’s worth a read (if you read French or accept Google Translate in Chrome at face value), as Julie makes several good points. She also points to more resources, on top of the ones I’ve listed. If you wait a little while longer, an English translation may materialize.
I recently completed Coursera’s “The Data Scientist’s Toolbox” course presented by Johns Hopkins University. This 4-week course offers a broad overview of what data science is and how to set up your “toolbox” for R programming and analysis of data. Below are my takeaways that have inspired me to continue to learn more about data science and R:
Data science begins with formulating the right questions and finding the right data set before bringing in math/statistics and hacking (programming) knowledge. This is part of the experimental design process.
A data science is broadly defined as someone:
“who combines the skills of software programmer, statistician and storyteller slash artist to extract the nuggets of gold hidden under mountains of data”
RStudio is a go-to graphical interface (application) to start developing R projects right away.
RStudio plays well with Github.
R’s strength is statistical computing.
R has a markdown package! It can “knit” your project together into HTML, PDF, or Word document.
There are 6 general categories of data analyses:
descriptive: summarizing a data set (U.S. census)
exploratory: exploring data to find relationships (% of women in specific work sectors)
inferential: generalizing from a small sample to reflect on a larger group (air pollution in small area infers how all of US residents are impacted by pollution anywhere)
predictive: using historical data to predict what happens next (elections)
causal: exploring cause & effect of variables upon each other (trials for drugs)
Experimental design begins with choosing variables (independent and dependent) in order to formulate an hypothesis (expected outcome) about which variables will be affected or changed.
An independent variable (factor) is often the X-axis when plotted.
The dependent variable is often the Y-axis when plotted.
Big data is defined by volume (more data), velocity (data is being generated quickly), and variety (data is available in several formats).
Important note: I did not pay to take this course. I audited it for it’s core content, therefore, was unable to take any of the module quizzes or submit a course project. This is a good course to use as a way to explore if data science is an area you’d like to get to know and explore.
Statistics was a weakness of mine in undergraduate coursework, but asking questions, doing math, and writing code don’t scare me. So! Next up in my exploration of data science: R Programming on Coursera.
2018 was my year to drop time wasters and get serious about my time. My priority is my family (husband and son), but I also care deeply about a fulfilling career (web development and accessibility). Those two things don’t leave me with much time when I want them both to flourish. So, I decided to commit myself to deep work with some room left for hobbies.
Cutting back on social media
Part of getting serious meant dropping usual distraction suspects, starting with Facebook. On June 22, 2018, I deleted my Facebook account and haven’t looked back since.
Taking back my distracted life, one minute at a time:
✅ Facebook account deleted.
A week later, I deleted the Twitter app from my phone. LinkedIn and Goodreads apps had already been removed a year ago. At that time I’d also reined in phone notifications to only important messages and calls.
Replacing dead reading time with valuable reading
That reasoning of deleting social networks was not only inspired by Cal Newport’s Deep Work, but also by the logic that I could easily fill those random moments with a book rather than valueless posts. I took up a mixture of audiobooks and e-books to champion that lofty goal. As a result I surpassed my Goodreads goal of 30 books. I actually read 95 books! (Note: a quarter of that number was books that I read to my son and wanted to remember later on.)
So, instead of reading the microposts my friends, family, and groups posted, I filled that time with autobiographies, classic literature, and web dev books. To place more value on my time, I never stayed to long with a book that didn’t thoroughly engage me.
Learning and building with code
Reading wasn’t the only thing I spent my “free” time doing. In 2018, I’d made a point to get better at JavaScript. Or at least gain more confidence inside that language. By the end of the year, I successfully gained experience and confidence in coding with vanilla JavaScript. Several things happened that got me there:
Earned the Mobile Web Specialist nanodegree from Udacity, which forced me to build a web app that used an API to pull restaurant and location information, coupled with a form for user reviews
Worked on a side hustle web app that stretched my knowledge of Zurb’s Foundation framework, Ruby on Rails, UI design, and web accessibility
Earned FreeCodeCamp’s JavaScript Algorithms and Data Structures certificate
All the while, still able to make a total of 602 contributions on Github (a mixture of open source and personal projects)
The year of the web a11y
Alongside my aspirations to program with JavaScript, I didn’t want to abandon the interest I had in UX. The prior year I had already started my journey of learning about web accessibility, but I desired to deepen that shallow know-how. Through my full-time job, I was able to nurture that desire with the support of the people above and around me. The working group that I formed on a statewide level continued to meet. I created workshops and training materials to help my co-workers make more accessible documents. Additionally, I was able to create a few webinar presentations to reach designers and developers on a wider level.
This was the year I decided that accessibility is going to be a key component in my web design and development career. It matters to me, and I want it to matter to other people without being an extra burden.
Do I feel validated yet?
My ultimate goal last year was to see if I could do a lot of things despite the time constraints I felt as a mom, wife, and breadwinner. This past year showed me that, yes, I could make time for myself and for the things I wanted to work on. I could also make advancements in those in-between spaces of home life and work life. I didn’t get a new job (that wasn’t my intent), but I did get the confidence boost I needed to pull me out of imposter syndrome and the code newbie feeling. Additionally, I was able to make projects for myself, giving me personal validation that my learning and viewpoints matter, therefore, giving me opportunity to make a difference around me.
What about 2019?
I’m getting a late start here when it comes to reflecting on the last 365 days, and how I’d like to succeed in the next 365. Then again, it’s only appropriate. Though I accomplished so much for myself in 2018, I want to slow down a bit in 2019. I don’t want to rush through all the things to say that I did a ton of things. Alternatively, I want to create space for more reflection and increase the value from the things that I will interact with.
Second, I realize I need to remember this quote more frequently:
“Comparison is the thief of joy.” – Theodore Roosevelt
Comparing myself to others pushed me forward to do more for myself, but it also set me back. It doesn’t let me go at my own pace, and embrace my own unique self. It puts more value on other people’s values rather than discovering my own.
Happy New Year, everyone! May the coming days be enriching and of value to all of us, no matter what our goals, milestones, and pace. Be the best you.
Carney Develop It 