Accessibility Team Meeting Notes: January 15, 2021

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Discuss the Goals for WordPress 5.7

Collect updates/feedback from the different working groups.

  • Media: moving through older TRACTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets.
  • Docs and accessibility patterns: no updates to share. Require feedback on documenting accessibility patterns.
  • Start the ground work of phasing out the accessible view in the widgets screen: GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ may be replacing the widgets screen, more to come soon.
  • Making sure there is a plan in place to have team to team communication to help with WordPress Learn: @alexstine will attend the meetings and help out the Learn team with cross-communication.
  • More Accessibility Ready tag reviewers for themes team: more frequent training around theme review guidelines. The possibility of pre-recording training sessions for independent learning.

Discuss the Gutenberg GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue about “Avoid focusing blocks when inserting them into the canvas”

Discussion will continue in the GitHub Issue. @ryokuhi wrote a summary in the issue on what was discussed in the meeting.

Open floor

There was a super quick open floor, but nothing new was brought up.

#meeting-notes

Accessibility Team Meeting Notes: January 8, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Review of the working groups’ activities

During holiday season, there were no accessibility team’s meetings, so the main goal of the meeting was to get updates from the various working groups and identify areas that most need some extra help, to make good use of the time left before 5.7 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process..

Documentation

@Hauwa Abashiya reported that last discussion happened before Christmas and that the group agreed to continue to work on accessibility patterns.

Media

@joedolson reported that some triage was done and that there are some plans, but given the holidays only little work was done. The working group will need some extra help before beta, especially from developers who know the media library (and there are only a few of them, unfortunately).

Themes

@poena left a note before the meeting to inform that the Themes Team moved forward all themes with the accessibility-ready tag under review.

@joedolson reported that the Accessibility Team and the Themes Team joined forces to update the accessibility-ready guidelines to improve clarity and include some new requirements added for WordPress 5.5. The draft about proposed updates to requirements for accessibility-ready themes is public and contributors are invited to leave their feedback.

GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/

@annezazu reported about the first in a series of call for testing for the Full Site Editing outreach experiment. Feedback is due by Wednesday, January 13th, but the date can be extended if needed. More call for testing will follow, this one was mainly highlighted to remind team contributors about this opportunity.

@sarahricker asked the team to follow two Gutenberg issues that are considered must-haves for WordPress 5.7:

Contributors are also invited to have a look to the Accessibility audit project board.

Design

@sarahricker reported her plan to continue with joint office hours between accessibility and design teams.

@jameskoster asked for feedback about the desing of the issue about making the block navigator persistent and adding hover indication on the canvas before it moves to development.

MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.

@joedolson suggested to open a ticket to improve the exposure of information about accessibility-ready themes.

General

The bug-scrub before the meeting was very productive: all tickets in the 5.7 milestone have an owner, so they are monitored by at least one team contributor.

Open floor

@Hauwa Abashiya asked if some team contributors could attend the meetings of the new Learn working group. Next meeting is on Thursday, January 20, 2021 at 15:00 UTC, after that meetings will be every first and third Thursday of the month at 19:00 UTC.

@sarahricker asked to include updates about the team goals for WordPress 5.7 in the next meeting agenda.

@alexstine asked for some extra testing on ticket #52073.

#meeting-notes

Accessibility Team Meeting Notes: December 18, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Main team goals for WordPress 5.7

A short while ago, the team published a post on the blog asking for suggestions on what to work on in WordPress 5.7. Accessibility Team’s goals for WordPress 5.7 and beyond Here is what the team has decided to focus on.

  • Media
  • Docs and accessibility patterns
  • Start the ground work of phasing out the accessible view in the widgets screen
  • Making sure there is a plan in place to have team to team communication to help with WordPress Learn
  • More Accessibility Ready tag reviewers for themes team

Discussion about teams activity during the holiday season

It was decided that teams and sub groups would operate asynchronously through the holiday season. An extra bug scrub was proposed if it ended up being needed.

Open floor

There was not enough time remaining for open floor.

#meeting-notes

Accessibility Team Meeting Notes: December 11, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Review of the team’s activities for 5.6 release

WordPress 5.6 is out since Tuesday, so the team reviewed the main accessibility achievements of the release.

  • The blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor now supports adding captions and subtitles to videos
  • The new Twenty Twenty-One theme is not only accessibility-ready, but also addresses more specialized standards from WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.1 at level AAA
  • A feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. to add an accessibility statement has been worked on during the release
  • Documentation is being rewritten to better describe accessibility patterns and antipatterns

Also, the team was able to build bridges with other teams, component maintainers and focus areas: this was greatly valued both inside the team and from the outside, and cooperation will hopefully improve even more when the new organization of the team in working groups will come into effect.

Team members were in general satisfied with the achievements and are looking into reaching even greater results in the next release.

Planning of weekly meetings during holiday season

Given that December, 25th and January, 1st fall on Friday, no meeting will happen on these days. This means that the next but one meeting will be on January, 8th.

The 5.7 development cycle hasn’t been defined yet, but the release is currently planned for March 2021, so the alpha period will happen mostly during the holidays.

A first step to set and reach targets would be to collect ideas: whoever wants to make a suggestion is invited to add a comment to the self-contained post about accessibility goals for WordPress 5.7.

During next weekly meeting, suggested goals will be discussed, but in the end it will be up to each working group to decide what to focus on for the release, based on the number of contributors and their time availability.

During holiday season, each working group will organize on its own. If needed, extra meeting and/or bug scrubs can be organized, but contributors are always encouraged to work asynchronously and ask for help at any time in the channel.

More details will be worked out during next weekly meeting.

Open floor

@Hauwa Abashiya asked what would be the best way for the training team to reach out for help from the accessibility team regarding accessibility questions raised in the creation of the learn.wordpress.org platform.

Given that most of the work is done in the GitHub repository of the learn WordPress project, it was suggested to create a specific label, so that team members can quickly identify issues related to accessibility.

#meeting-notes

Accessibility Team Meeting Notes: December 4, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Nomination of the working groups’ referents

In previous meetings, it was proposed and agreed to create working groups inside the team to better address the various aspects of WordPress accessibility. Ideally, each team should have a referent; their role would be:

  • keep track of what the group is working on
  • report about it during weekly meetings
  • ask for the team’s help to solve specific issues

Some contributors already volunteered as referent for a working group:

The teams who still need a referent are:

  • editor
  • general
  • metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.
  • themes

After some discussion, the team agreed that, until someone decide to volunteer, teams that don’t have a referent yet will start without one and will fill the role later.

Result of the extra bug-scrub focused on 5.7 release

On Tuesday, December 1st, an extra bug-scrub focused on preparing the 5.7 release took place: you can find the full transcript on the #accessibility Slack channel. @sabernhardt, who facilitated the bug scrub, reported quickly about the results.

  • Ticket #45925: the good-first-bug label was added and @danfarrow became the owner
  • Ticket #32510: needs some research and testing
  • Ticket #45141: needs testing from a regular keyboard user (@alexstine volunteered)
  • Ticket #42780: will need testing after an external library update
  • Ticket #49696: needs exploration

All contributors are invited to have a look at these tickets, add their thoughts and check if they can be solved in the next release

Open floor

@ryokuhi drove attention to a couple of topics that were raised the week before the meeting and that would benefit from some attention by accessibility contributors:

#meeting-notes

Accessibility Team Meeting Notes: November 27, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Badge assigning to team members and contributors

Badges are usually assigned twice a year and one of those days is today (Friday November 27, 2020.) One of these badges is Accessibility Contributor and the other is Accessibility Team. Accessibility Contributor is for those that contribute a few hours or attend the meetings while Accessibility Team is for the ones that put in a lot of time by commenting on tickets, testing/making patches, and attending meetings. @joedolson will be handling the badge assigning.

Working groups’ referents nomination

This agenda item was skipped until a future week due to the absence of people from the holidays.

Discussion about dedicating a bug-scrub to labelling good-first-bug tickets and issues

@sabernhardt has offered to step up and lead a special bug scrub. The first one will be held Tuesday December 2, 2020 at 16:00 UTC. A big thank you to @sabernhardt who has offered to lead! The main focus would be on Accessibility tagged tickets for Future Release.

Open Floor

Some discussion around sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. accessibility was brought up: review here

#meeting-notes

Accessibility Team Meeting Notes: November 13, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. nominations

The team accepted nominations for a new Team Rep and we’re happy to share that both @alexstine and @sarahricker have been nominated for the role.

Given that more than one person was nominated, we are going to open a voting round so folks can vote for the person they’d like to see as our new Team Rep.

Please follow this link to vote https://forms.gle/Bwv1PqGqhVQ9VuE28. The survey will be open until Friday, November 20, at 16:30 UTC.

Organization of team sub-groups

We discussed and decided to move forward with the idea of organizing our team around sub-groups. This will allow members of our small team to focus on specific areas of interest and expertise. The groups are:

  • Editor
  • Design
  • Media
  • Themes
  • MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.
  • Docs
  • General

Folks have already shown interest on the areas they’d like to participate in, so we’re going to give this new organization structure a try for the WP 5.7 release and we’ll adjust and adapt as necessary.

5.6 projects status

@sarahricker, our WP 5.6 Accessibility Release Coordinator, shared a status on the different projects the team is juggling during this release.

The Accessibility Statement pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is currently being promoted in the About page. Help is needed reviewing the content of the generated statement. You can test and give feedback here.

@joedolson and @Hauwa Abashiya have been hard at work on the new pattern library to support WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.1. Please refer to the #accessibility-docs SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel for more info on how you can help.

The new Twenty Twenty-One theme is moving along and they need help testing the new dark mode.

#meeting-notes

Accessibility Team Meeting Notes: October 30, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Team meeting time change

Starting Friday, November 6 2020, our team meeting and bug scrubs times will shift one hour to accommodate the recent end of daylight savings time across the world.

The team meeting will now be held at 16:00 UTC, and the bug scrub at 15:00 UTC. Please refer to the WordPress Meetings Calendar for more info.

Upcoming Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. call for nominations

As my term as Team rep comes to an end, we’ll be holding a call for new Team rep nominations during our next meeting. Depending on the number of nominations, we’ll define if we will be holding a voting round after the meeting.

If you are interested in the role or know someone who would be a great fit, next week you’ll have the opportunity to nominate yourselves or others for the role.

Please feel free to reach out to @ryokuhi or me (@nrqsnchz) on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. if you have any questions about the role or the process.

Improvements to team workflows

The team held a discussion on our process around discussing issues and tickets in our team channel and during our team meetings.

The topic of working asynchronously came up, as we don’t always have the time to cover everything during our meetings, and tangentially not everyone is able to attend our weekly meetings for various reasons.

We also talked about creating sub-groups on our team that can focus on specific areas of interest and expertise. We are very mindful of the limited resources our team has, and we think being smart about how we each spend our time is something we need to improve.

We agreed to pick up this conversation during our next meeting and start organizing the team around this idea.

#meeting-notes

Accessibility Team Meeting Notes: October 16, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Discussions of ticket #50699: Fix and improve arranging metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes

We discussed Trac ticket #50699 that looks to limit the reordering of meta boxes to only when the Screen options panel is opened.

We raised a concern that removing the up/down buttons from meta boxes will likely affect users of assistive technologies, and will make it harder for someone using a keyboard to interact with this feature.

We agreed to test the patch and leave our feedback in the ticket.

Feedback con Twenty Twenty-One accessibility issues

We reviewed a couple of accessibility-related issues on the development repo of Twenty Twenty-One, the new default WordPress theme.

Consider removing the underline on the post titles to improve readability

This issue is suggesting to remove the underline on some links, particularly in post titles. Underlines can have a negative effect on the readability of text for users with dyslexia.

In light that the team behind the new default theme wants it to be as accessible as possible, we acknowledged that there is no one size fits all, and for now keeping the underlines seems to be the most widely accessible solution.

Our feedback was added to the issue.

Consider using the default focus outline style set by the browsers

Related to the previous discussion point, this issue is also related to link styles, in particular the style used for the focus state of links.

The issue suggest to remove the border style and use browser defaults instead. While we had added some alternative proposals to the issue, it seems that the default outline style is the best solution for now.

#meeting-notes

Accessibility Team Meeting Notes: October 2, 2020

These are the weekly notes for the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Team meeting that happens on Fridays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

It’s WordPress Accessibility Day 🎉

Today is WordPress Accessibility Day, a 24-hour global event dedicated to addressing website accessibility in WordPress. You can find out more about the schedule and sessions on wpaccessibilityday.org.

Progress report of the team’s goals for 5.6

We reviewed progress on the main team goals for WordPress 5.6:

  1. Updating the WordPress Accessibility coding standards from WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.0 to WCAG 2.1 and document accessibility anti-patterns
  2. Accessibility of the WordPress Twenty Twenty-One default theme
  3. A feature plugin to create an “Accessibility Statement” tool with features equivalent to Privacy Policy Tools

Updating the WordPress Accessibility coding standards from WCAG 2.0 to 2.1

The team started work on the documentation but we are still pending on gathering examples of anti-patterns found across WordPress’ interface.

Please reach out if you want to help with this task.

Accessibility of the WordPress Twenty Twenty-One default theme

Folks behind the design and development of the new WordPress Twenty Twenty-One default theme have already been at work creating and addressing accessibility-related issues.

Some of these issue have proven to be complex and feedback is welcome. The team feels that we need to clarify our goal of having the theme be AA or AAA ready.

Accessibility Statement feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.

The pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is ready to be downloaded and testing help is needed.

Organize accessibility testing of the new Widgets screen

A call for testing the new Widgets Screen in Gutenberg 9.1 was posted earlier this week.

The accessibility team is planning and organizing a round of accessibility-related testing. The call for testing goes into detail on how to test and provides more details, but in summary, in order to test this screen you’ll need to:

  1. Have a site using WordPress 5.5.
  2. Make sure you use a theme that supports widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas (e.g. TwentyTwenty).
  3. Go to the website’s admin.
  4. Install and activate the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin. If you already have it installed, make sure you are using at least Gutenberg 9.1.
  5. Go to Appearance > Widgets.
  6. Notice that it visually resembles the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor now.

We welcome any help with testing the new Widgets Screen. Whether you can test for keyboard access, screen-reader support, or any other type of assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology, a few tasks you can test for are:

  1. Navigate and have access to the whole interface
  2. Add/remove blocks and 3rd party widgets
  3. Move widgets around

If you’re specifically testing for keyboard access, please check that:

  • any action can be performed easily with keyboard only
  • the tab order is logical and meaningful
  • there are no keyboard traps
  • users are not forced to perform counterintuitive keyboard navigation to perform an action

Please open issues on the GitHub repository so these findings get addressed as soon as possible. In order to avoid duplication, we ask you to share in the #accessibility channel when an issue is created so everyone has awareness and follow along.

If you have access to add labels in the repository, the label we should be using for these issues is [Feature] Widgets Screen.

#meeting-notes