React Accessibility (React Finland)

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.

The full presentation is 2 hours long.

Path Object Not Tagged (PDF problems)

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 with 429 fails: PDF/UA > Basic Req. > Content > Tagged content & artifacts > Path object not tagged.
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).

Mouse cursor over Content panel icon: "View & edit page content information".
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:

  1. Open the Tools panel.
  2. Open the Print Production tool.
  3. Select Preflight.
  4. Ensure PDF Standards is selected in the first dropdown menu.
  5. in the Profiles tab, search “artifact”.
  6. Under the Document accordion.
  7. Select “Mark all non-structure elements as artifact” option.
  8. Activate the Fix button.


Preflight dialog box. Search "artif" and select "Mark all non-structure elements as artifact" All steps listed before this image.
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!

Learn More

Some of my go-to resources for PDF accessibility:

Tools I use to check PDF accessibility:

  • Adobe Acrobat Accessibility Checker
  • PAC3
  • NVDA screen reader

People to know:

  • Karen McCall
  • Duff Johnson
  • Duff Johnson
  • Jennie Delisi

7 Reasons Why Accessibility Overlays Aren’t a Magical Solution

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…

  1. Often haven’t been verified to work well, if at all.
  2. Don’t actually fix bad code or design.
  3. Put the burden on users to learn your site tool rather than just using their assistive tech or adaptive strategies.
  4. May even conflict with the visitor’s assistive tech or customizations they use on their computer/phone.
  5. 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.
  6. Only “solves” accessibility on your website; it doesn’t create a usable experience throughout the web as visitors travel between sites.
  7. 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.

Learn from the experts

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.

A Glimpse into R and the Data Scientist’s Toolbox

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:
    1. descriptive: summarizing a data set (U.S. census)
    2. exploratory: exploring data to find relationships (% of women in specific work sectors)
    3. 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)
    4. predictive: using historical data to predict what happens next (elections)
    5. causal: exploring cause & effect of variables upon each other (trials for drugs)
    6. mechanistic: measuring exact variable differences (material science experiments)
  • 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.

In 2018: I Took Back My Time

Wall clock reads 5:51.
Photo by Buenosia Carol on

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.

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
    MWS Certificate of Completion on November 12, 2018.
  • 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
    FCC JavaScript certificate.
  • All the while, still able to make a total of 602 contributions on Github (a mixture of open source and personal projects)
    Github contribution chart: 602 in 2018.

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.


Normative vs. Non-normative

In my current journey to thoroughly study and understand web accessibility, I had a question that I needed to ask the Internet about W3C documentation:

“What is the difference between normative and non-normative?”

I found a great explanation on StackOverflow by Michael Kay:

“Normative” means that it’s an official formal part of the specification; non-normative means that it’s there to be helpful and aid understanding, but you can’t appeal to it in a court of law (so to speak).

I’ve heard the terms “normative” and “non-normative” used when referring to web standards documentation and accessibility help, but I had no clue what that meant. To me, the above explanation makes it clearer in my mind:

  • normative: official and approved wording; holds up in a court of law
  • non-normative: an aid that breaks down the specification; often tutorials

As I began working through IAAP’s Web Accessibility Specialist Body of Knowledge (Word doc), I noted differences were clearly specified:

I wanted to point out these specific examples because this is one area where I’ve been hesitant to dive in deep. I’ve jumped into the WCAG (normative) docs many times for one reason or another, but had not spent much time there. On the flip side, I’ve spent lots of time reading through How to Understand WCAG (non-normative). It cites the normative documentation, but makes information a lot easier to read, digest, and assimilate into my own knowledge base.

Launching 100 Days of A11y Site

Side profile shot with cartoon blue beanie superimposed on head.

In honor of Blue Beanie Day (November 30) and in conjunction with my own preparation for IAAP’s Web Accessibility Standards certification exam, I’m committing to a second round of 100 Days of Accessibility and launched an 100DaysOfA11y website to keep me accountable. My hope during my study process is to provide you digestible snippets about web accessibility that I’ve learned or inspire you to dive deeper into W3C docs and tutorials about accessibility standards. In turn, documenting my process will help me internalize what I’ve learned.

Wish me luck, follow my journey, and Happy Blue Beanie Day!

Synchronize Files in Dreamweaver

Dreamweaver CC opening window.Is anyone out there still using Adobe Dreamweaver in 2018? I am. It’s my text editor of choice at work because 1) it was given to me to use, and 2) it seamlessly puts my files from my local environment to the production server. One of the features I’ve recently discovered, and love to use now, is how to synchronize files. It took away that pain-staking effort of comparing orphan and revised copy files between those two servers. The thing I didn’t know was that I could delete those files without having to actually get or put anything on the production server. All I wanted to do was delete files that were no longer needed in production.

How I Synchronize Files to Delete

  1. Right-click on the folder that I want to target and synchronize. Select “Synchronize..”
    Right-click dialog with mouse focus on Synchronize.
  2. From the Synchronize with Remote Server dialog, under “Direction”, choose “Put newer files to remote”.
  3. Check the “Delete remote files” checkbox. This is the important part. I think “Put” and “Get” are irrelevant for what we’re trying to accomplish here.
    Synchronize with Remote Server dialog with mouse focus on Preview.
  4. Click “Preview…”
  5. The “Synchronize” dialog will appear, listing what files will be deleted. If you have files that are identified under the “Put” Action, of which you aren’t ready to put yet, just select all those files, and use the circle-backslash symbol in the bottom left to ignore those files.
    Synchronize dialog showing a list of files to be deleted.
  6. Now for the heart-stopping dialog box: “Do you really want to delete the selected file(s)? YES. Yes, I do.
    Dreamweaver dialog asking permission to delete.

That’s it! It’s pretty straight-forward, and I no longer have orphan files living on my production server. Word from the wise, take small chunks at a time. For me, this is a process I embrace while making revisions to file names and deleting documents within my local environment. You could do it at the root level, but I’m not ready for that mess yet.

A Final Thought

The division I work for hasn’t instated any type of version control, like Git (it’s a dream of mine, though!), so I’m left wondering if that would replace the issue of orphan files and file renaming. Until then, this is my method to cross that divide.

My Question to You

What text editor do you use? And how are you able to synchronize your files between local and production environments?

Two New Shortcuts Added to My Web Design Toolbox


One perk about the web designer and developer life is that I’m always learning. Always. Today I learned how to…

Quickly convert content to code

Today I found myself pulling out the headphones, turning up the Moana soundtrack, and tediously beginning the manual process of copying content in between HTML tags. About a quarter of the way into this process, I stopped and told myself there needs to be a better way. I thought to myself, “if only some of these pages had a CMS editor for my co-workers to add basic content to… Wait!” That’s when I realized we have a CMS for one of our sites. I managed to save my entire afternoon by copying the Word content into this CMS editor, copying the “Source” view, and pasting it into the new page I had set up.

Work order closed. Next project initiated.

Remove all hyperlinks in a Word document

While doing the copy and paste, as mentioned above, I found a few formatting issues that needed to be corrected. One of them being that each list item had a non-visible hyperlink. Likely an oversight on the part of the person who gave me the document. The problem was that those links all led to 404s because I took down those inaccessible PDFs over a month ago.

Again, the programmer’s mindset nagged me. There had to be a way to remove hyperlinks in one fell swoop! Thanks, TechWalla, for giving me the keys (pun intended) I needed to accomplish this task in 2 seconds:

  1. Ctrl+A (select all content)
  2. Ctrl+Shift+F9 (remove hyperlinks)

Hyperlinks eradicated!

A Final Thought

A mixture of design and development at my job has been fulfilling. But most of all, both tasks have been very complimentary. I try to think from the perspective of how a user is interacting with our pages. Additionally, I think of how to make my own work (and those after me or collaborating with me) more efficient, so more time can be spent on a thoughtful user experience. The teeter-totter of design and development. Or is it circular, one blending into the other, with no bold black lines?

Troubleshooting: Using JSON on IIS

Problem. Analysis. Solution.

Progressive web apps, also known as PWAs, are hot and happening right now. If you’ve been keeping up on web development in 2018, you’ll likely have heard about them.

I’ve been learning about them most of the year through Udacity’s Mobile Web Specialist nanodegree program that I’m about to graduate from. To add icing to that cake, I recently finished Jeremy Keith’s Going Offline, which also explains what a PWA is.

What is a PWA anyway?

In case you’re still scratching your head about what exactly a PWA is, Keith explains it as meeting three criteria:

  1. It’s served over HTTPs.
  2. It works offline with a service worker.
  3. It has a web app manifest file.

That’s it! During the last five years of my experience in web development, it’s clear to me that some websites are not so easily categorized as web applications or static. Lots of crossover is occurring these days.

Taking the PWA challenge

Thanks to Udacity and Jeremy Keith, I feel like I’ve gotten a better handle on nudging my personal projects into being more offline-friendly. That being said, I was ready to venture into bringing some of these ideas into my workplace, starting with the manifest file. Easy, right? I mean, what could be so hard about adding a JSON file? Nope. I was reminded that many moving parts make web development more complicated than I anticipate it to be. Let me show you.

First, I created the manifest file:

"lang": "en-us",
"name": "Alaska State Museums",
"short_name": "State Museums",
"author": "Alaska State Museum",
"description": "Online presence of the Alaska State Museum in Juneau and Sheldon Jackson Museum in Sitka.",
"theme_color": "#c30017",
"background_color": "#333",
"start_url": "/",
"display": "minimal-ui",
"icons": [
"src": "/images/logos/logo-sm.png",
"sizes": "48x48",
"type": "image/png"
"src": "/images/logos/logo-lg.png",
"sizes": "512x512",
"type": "image/png"

Next, I linked the file in the head of my document. In my case, I added it to an include file (don’t judge me for my old ASP.NET method):

<link rel="manifest" href="/manifest.json">

It’s that simple really. And yet, Chrome kept giving me a 404 error after acknowledging that link reference, but found no file. Even though the manifest file was listed in DevTools! It’s there, but it’s NOT there?? I just couldn’t understand where I could go wrong with a manifest file. The path was correct. The data was correct. I was stumped.

To make a long story short, it dawned on me (a few hours later) that the server at work (IIS) might just be hindering my efforts. So, I did some googling, and StackOverflow came to my rescue: How to allow download of .json file with ASP.NET.

I don’t always have access to our server, but I do have the control to update a web.config file. So, I happily took their advice and added this to the web.config file that already existed:

    <mimeMap fileExtension=".json" mimeType="application/json" />

Magic! Suddenly DevTools picked up the file and I passed that part of the PWA Lighthouse audit.

Confidence Restored

Now that this “simple” fix has resolved today’s issue, I’m ready to turn back to a project I was working on several months ago that I thought I’d failed due to poor JavaScript syntax that I’d written. This learning moment has re-established confidence in my competency, and I have no doubt my next project will go a little smoother since this JSON-used-on-IIS hurdle has been removed.