Improve Accessibility

[cjyabraham]

• Overall ideas and plan for accessibility on the LF Events site
• Analysis and recommendations

Current plan if for James/Chris to start improving the accessibility of the site. Once they've done what they can, we can discuss with Kristin/Angela about making a stronger commitment to accessibility for the site. If we get this we can move forward with publishing an Accessibility Statement, new requirements for incoming event designs/assets, and any further communications.

Improvements needed:

• Enable sponsors to have alt text and for better title text on links on sponsor images in sponsor block
• Add new field to sponsors "display name" that can override the sponsors name if needed
• Install PublishPress Checklists plugin and set to require alt text for all images
• Check social links in speaker block for accessibility issues
• Update speakers images to have alt text
• Fix accessibility of hamburger button
• Add alt text to LF logo
• Fix aria roles on speakers and footer
• Fix accessibility issues with missing labels on the newsletter forms (note: this is also a problem on cncf.io)
• Image box has empty link and no alt text on the image
• Tables ("schedule at a glance") need column headers set for screen readers, optionally have a screen reader caption
• Update menu to be controllable by keyboard and insert skip link
• Made cookie colors less garish

After this initial work, we could follow up with the following:

• Get buy-in from Angela/Kristin for being more public about our work
• Publish a list of guidelines for Event authors so that they can design for accessibility from the outset and also so that Nicole can reference them when and Event design needs improving
• Publish an Accessibility Statement, similar to that of CNCF, and link to it in the footer
• Publicize our work on this and reasons for doing it when it’s done to build awareness within the team (see doc written for CNCF); possibly write a blog post to be published on the LF Events site

[thetwopct]

@cjyabraham Could you have a look at Hubspot to see if we are able to fix the form label issues? I only have CSS control of the embed form it seems - it's inserted via short link:

echo do_shortcode( '[hubspot type=form]' );

[cjyabraham]

I don't think I can omit the labels. One option, however, is we provide labels but hide them with our own CSS? Or we just skip this one...

[thetwopct]

Hubspot allows us to add a label for each form field. I've now added the CSS so that will be hidden (as per the design) and only read for screen readers. Once this PR is merged, we will have to update the footer form with the labels.

[thetwopct]

Regarding the tables, I miss-remembered how they were made - I thought they were custom blocks already. But we are using default WordPress tables. This means:

• There is already a caption option on them (I have styled it in the editor to be a bit more obvious, and hid it on the frontend as screen reader text).

- There is already an option to add a header section. I think adding a header looks fine, so maybe the team can just start doing that? If not we need another solution TBD.