-
Notifications
You must be signed in to change notification settings - Fork 228
Descriptive Alt text
We have committed to providing alt-text for all figure images, plots and graphs included in our lessons.
Alt-text is integrated into the liquid syntax we use to include images. The required format is:
{% include figure.html filename="file-name.png" alt="Visual description of figure image" caption="Caption text to display" %}
There are (lots of) guidance notes about how to write good alt-text around online, but we haven't developed something PH-specific yet.
We have found Amy Cesal's guide to Writing Alt Text for Data Visualization useful. This guide advises that alt-text for graphs and data visualisations should consist of the following:
alt="Chart type of data type where reason for including chart"
What Amy Cesal's guide achieves which we think is important, is prompting an author to reflect on their reasons for including the graph or visualisation. What idea does this support? What can a reader learn or understand from this visual?
The Graphs section of Diagram Center's guidance is also useful. Some key points (relevant to all graph types) we can take away from it are:
- Briefly describe the graph and give a summary if one is immediately apparent
- Provide any titles and axis labels
- It is not necessary to describe the visual attributes of the graph (colour, shading, line-style etc.) unless there is an explicit need
- Often, data shown in a graph can be converted into accessible tables
For general images, Harvard's guidance notes some useful ideas. A key point is to keep descriptions simple, and adapt them to the context and purpose for which the image is being included.
Hello @Author,
The syntax which we use to embed figures within our lessons includes an 'alt-text': this descriptive element enables screen readers to read the information conveyed in the images for people with visual impairments, different learning abilities, or who cannot otherwise view them, for example due to a slow internet connection. It's important to say that `alt-text` should go further than repeating the figure captions.
We have found [Amy Cesal's guide to Writing Alt Text for Data Visualization](https://medium.com/nightingale/writing-alt-text-for-data-visualization-2a218ef43f81) useful. This guide advises that alt-text for graphs and data visualisations should consist of the following:
`alt="[Chart type] of [data type] where [reason for including chart]"`
What Amy Cesal's guide achieves is prompting an author to reflect on their _reasons_ for including the graph or visualisation. What idea does this support? What can a reader learn or understand from this visual?
[The Graphs section of Diagram Center's guidance](http://diagramcenter.org/specific-guidelines-e.html) is also useful. Some key points (relevant to all graph types) we can take away from it are:
- Briefly describe the graph and give a summary if one is immediately apparent
- Provide any titles and axis labels
- It is not necessary to describe the visual attributes of the graph (colour, shading, line-style etc.) unless there is an explicit need
- Often, data shown in a graph can be converted into accessible tables
For general images, [Harvard's guidance](https://accessibility.huit.harvard.edu/describe-content-images) notes some useful ideas. A key point is to keep descriptions simple, and adapt them to the context and purpose for which the image is being included.
Would you feel comfortable making a first draft of the alt-text for each of the figures? This is certainly a bit time-consuming, but we believe it is very worthwhile in terms of making your [LESSON/TRANSLATION] accessible to the broadest possible audience. We would be very grateful for your support with this.
Thank you,
- Copyediting
- Copyedit comments
- Typesetting
- Archival Hyperlinks
- Copyright
- DOI
- Gallery image
- Checklist comment
- Handover comment
- Closing comment
- Opening comment Phase 0
- Phase change comment 1 to 2
- Phase change comment 2 to 3
- Phase change comment 3 to 4
- Opening comment Phase 4
- Phase change comment 4 to 5
- Phase change comment 5 to 6
- Phase change comment 6 to 7
- Tracking lesson phase changes
- Organisational Structure
- Trustee Responsibilities
- Trustee and Staff Roles
- Services to Publications
- Funding
Training
- Onboarding-Process-for-New-Editors
- Leading-a-Shadowing-process
- Board-of-Director---Continuing-Development
The Ombudsperson Role
Technical Guidance
- Making Technical Contributions
- Creating Blog Posts
- Service Integrations
- Brand Guidelines
- French Translation Documentation
- Technical Tutorial on Translation Links
- Technical Tutorial on Setting Up a New Language
- Technical Tutorial on Search
- Twitter Bot
- Achieving-Accessibility-Alt-text-Colour-Contrast
- Achieving-Accessibility:-Training-Options
Editorial Guidance
- Achieving Sustainability: Copyediting, Typesetting, Archival Links, Copyright Agreements
- Achieving Sustainability: Lesson Maintenance Workflow
- Achieving Sustainability-Agreed-terminology-PH-em-português
- Training and Support for Editorial Work
- The-Programming-Historian-Digital-Object-Identifier-Policy-(April-2020)
- How to Request a New DOI
- Service-Agreement-Publisher-and-Publications
- ProgHist-services-to-Publications
- Technical Tutorial on Setting Up a New Language
- Editorial Recruitment
Social Guidance
Finances
- Project Costs
- Spending-Requests-and-Reimbursement
- Funding Opportunities
- Invoice Template
- Donations and Fundraising Policies
Human Resources
- Privileges-and-Responsibilities-of-Membership
- Admin-when-team-members-step-down
- Team-Leader-Selection-Process
- Managing-Editor-Handover
- Checklist-for-Sabbaticals
- New Publications Policy
- Parental-Leave-Policy
Project Management
Project Structure
Board of Trustees