darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-04 12:58:25 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
e22e10e7acbf061f648ce330367e33eab45af556
notifications-admin/app/templates/views/broadcast/macros/area-map.html

41 lines
2.2 KiB
HTML
Raw Normal View History

Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
{% macro map(broadcast_message) %}
Rename CSS classes for consistency This prefixes everything to do with areas/the map with `area-list`, so from looking at one element you know which `.scss` file will contain the relevant code.
2020-10-05 13:47:21 +01:00
<div id="area-list-map"></div>
Change map key items from list to paragraphs I recently found that there is a problem with the overuse of lists online for sequences of content that don't need to be in a list. I think that's what we're doing with our map key. The problem is large enough that browsers include heuristics to determine if lists should be presented as such to the accessibility API (and so to assistive tech' like screen readers). This thread contains more details: https://twitter.com/cookiecrook/status/1337226933822603270 Based on the metric described in the thread: 'If all of the styles that make it “list-like” have been removed, it’s no longer relevant to convey it as a list.' ...or 'if a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know?' Based on that, I think the items in our map key should be paragraphs, not items in a list. Also, they read really well as sentences when announced by a screen reader, partly because of the extra (hidden) info @quis added to them. This also doesn't change their visual appearance.
2021-10-07 14:29:51 +01:00
<p class="area-list-key area-list-key--certain">
Make images in key of map SVGs At the moment, the icons in the key of the map showing what each type of area drawn on the map means change colour in high contrast mode. This causes a mismatch between the areas on the map and the key. These changes remake the images in SVG to prevent the colours changing in high contrast modes. They also add a white background to the icons, to make sure they match the areas they refer to in the map.
2021-11-03 19:50:12 +00:00
<svg class="area-list-key__icon" width="50" height="50" viewbox="0 0 50 50" aria-hidden="true" xmlns="http://www.w3.org/2000/svg">
<rect x="0" y="0" width="100%" height="100%" fill="#FFFFFF" />
<polygon points="25 5, 45 25, 25 45, 5 25" stroke="#0B0B0C" stroke-width="2" fill="#96C6E2" />
</svg>
Add GOVUK visually hidden style for map key The sentences in the key to the map have 2 forms: 1. the visual form, with an graphic pattern alongside text saying what the pattern means in the map 2. the semantic form, with text describing what the pattern means and how big an area it covers for this alert This is achieved by making the graphic non-semantic and having hidden words in the sentence for each paragraph. While the spaces between words are correct for both forms of these sentences, we observed screen readers speaking some groups of words as one when they spoke the sentence. Most noticably, 'the alert' was spoken as 'thealert'. Swapping the class used to hide the visually hidden words from ours to the GOVUK one seemed to fix this. It's unclear why it does but the `govuk-visually-hidden` class adds the following styles to those in ours: - width: 1px - height: 1px - white-space: nowrap It also has `margin: 0` instead of `margin: -1px`.
2021-11-04 15:09:25 +00:00
<span class="govuk-visually-hidden">
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
An area of {{ (broadcast_message.simple_polygons.estimated_area)|square_metres_to_square_miles|round_to_significant_figures(1)|format_thousands }} square miles&nbsp;
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
</span>
Will get
Add GOVUK visually hidden style for map key The sentences in the key to the map have 2 forms: 1. the visual form, with an graphic pattern alongside text saying what the pattern means in the map 2. the semantic form, with text describing what the pattern means and how big an area it covers for this alert This is achieved by making the graphic non-semantic and having hidden words in the sentence for each paragraph. While the spaces between words are correct for both forms of these sentences, we observed screen readers speaking some groups of words as one when they spoke the sentence. Most noticably, 'the alert' was spoken as 'thealert'. Swapping the class used to hide the visually hidden words from ours to the GOVUK one seemed to fix this. It's unclear why it does but the `govuk-visually-hidden` class adds the following styles to those in ours: - width: 1px - height: 1px - white-space: nowrap It also has `margin: 0` instead of `margin: -1px`.
2021-11-04 15:09:25 +00:00
<span class="govuk-visually-hidden">
the
</span>
Make estimated phone count clearer We’ve had some feedback from user research that difference between ‘will get alert’ and ‘likely to get alert’ is not clear, and it’s hard to tell if the latter is inclusive of the former. This leads people to question the validity of these numbers, which is important, because an the estimate should give you some idea of the impact of what you’re about to do. This commit reformats the number as a range, for example 1,000 to 2,000 phones. If the range is small, eg 40,000,000 to 40,800,000 then this suggests a false level of accuracy. So instead we just give one number and say it’s an estimate, eg ‘40,000,000 phones estimated’
2020-09-24 15:52:18 +01:00
alert
Change map key items from list to paragraphs I recently found that there is a problem with the overuse of lists online for sequences of content that don't need to be in a list. I think that's what we're doing with our map key. The problem is large enough that browsers include heuristics to determine if lists should be presented as such to the accessibility API (and so to assistive tech' like screen readers). This thread contains more details: https://twitter.com/cookiecrook/status/1337226933822603270 Based on the metric described in the thread: 'If all of the styles that make it “list-like” have been removed, it’s no longer relevant to convey it as a list.' ...or 'if a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know?' Based on that, I think the items in our map key should be paragraphs, not items in a list. Also, they read really well as sentences when announced by a screen reader, partly because of the extra (hidden) info @quis added to them. This also doesn't change their visual appearance.
2021-10-07 14:29:51 +01:00
</p>
<p class="area-list-key area-list-key--likely">
Make images in key of map SVGs At the moment, the icons in the key of the map showing what each type of area drawn on the map means change colour in high contrast mode. This causes a mismatch between the areas on the map and the key. These changes remake the images in SVG to prevent the colours changing in high contrast modes. They also add a white background to the icons, to make sure they match the areas they refer to in the map.
2021-11-03 19:50:12 +00:00
<svg class="area-list-key__icon" width="50" height="50" viewbox="0 0 50 50" aria-hidden="true" xmlns="http://www.w3.org/2000/svg">
<rect x="0" y="0" width="100%" height="100%" fill="#FFFFFF" />
<polygon points="25 5, 45 25, 25 45, 5 25" stroke="#005ea5" stroke-opacity="1" stroke-width="2" stroke-linecap="square" stroke-linejoin="round" stroke-dasharray="4,7.5,5,7.5,8,8,5,8,7.5,8,5,8,7,8,5,8,4" fill="#2B8CC4" fill-opacity="0.15" />
</svg>
Add GOVUK visually hidden style for map key The sentences in the key to the map have 2 forms: 1. the visual form, with an graphic pattern alongside text saying what the pattern means in the map 2. the semantic form, with text describing what the pattern means and how big an area it covers for this alert This is achieved by making the graphic non-semantic and having hidden words in the sentence for each paragraph. While the spaces between words are correct for both forms of these sentences, we observed screen readers speaking some groups of words as one when they spoke the sentence. Most noticably, 'the alert' was spoken as 'thealert'. Swapping the class used to hide the visually hidden words from ours to the GOVUK one seemed to fix this. It's unclear why it does but the `govuk-visually-hidden` class adds the following styles to those in ours: - width: 1px - height: 1px - white-space: nowrap It also has `margin: 0` instead of `margin: -1px`.
2021-11-04 15:09:25 +00:00
<span class="govuk-visually-hidden">
Update utils to do linear transformation of polygons Brings in https://github.com/alphagov/notifications-utils/pull/889/files At the moment, we are not doing any transformation of features before applying geometric algorithms to them. This is, in effect, assuming that the earth is flat. This new version of utils implements the transformation of our polygons to a Cartesian plane. In other words, it converts them from being defined in spherical degrees to metres. For the admin app this means we need to convert places where the code expects things to be measured in degrees to work in metres instead.
2021-08-03 18:46:30 +01:00
An extra area of {{ (broadcast_message.simple_polygons_with_bleed.estimated_area - broadcast_message.simple_polygons.estimated_area)|square_metres_to_square_miles|round_to_significant_figures(1)|format_thousands }} square miles is&nbsp;
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
</span>
Likely to get
Add GOVUK visually hidden style for map key The sentences in the key to the map have 2 forms: 1. the visual form, with an graphic pattern alongside text saying what the pattern means in the map 2. the semantic form, with text describing what the pattern means and how big an area it covers for this alert This is achieved by making the graphic non-semantic and having hidden words in the sentence for each paragraph. While the spaces between words are correct for both forms of these sentences, we observed screen readers speaking some groups of words as one when they spoke the sentence. Most noticably, 'the alert' was spoken as 'thealert'. Swapping the class used to hide the visually hidden words from ours to the GOVUK one seemed to fix this. It's unclear why it does but the `govuk-visually-hidden` class adds the following styles to those in ours: - width: 1px - height: 1px - white-space: nowrap It also has `margin: 0` instead of `margin: -1px`.
2021-11-04 15:09:25 +00:00
<span class="govuk-visually-hidden">
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
the
</span>
alert
Change map key items from list to paragraphs I recently found that there is a problem with the overuse of lists online for sequences of content that don't need to be in a list. I think that's what we're doing with our map key. The problem is large enough that browsers include heuristics to determine if lists should be presented as such to the accessibility API (and so to assistive tech' like screen readers). This thread contains more details: https://twitter.com/cookiecrook/status/1337226933822603270 Based on the metric described in the thread: 'If all of the styles that make it “list-like” have been removed, it’s no longer relevant to convey it as a list.' ...or 'if a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know?' Based on that, I think the items in our map key should be paragraphs, not items in a list. Also, they read really well as sentences when announced by a screen reader, partly because of the extra (hidden) info @quis added to them. This also doesn't change their visual appearance.
2021-10-07 14:29:51 +01:00
</p>
<p class="area-list-key area-list-key--phone-estimate">
Show broadcasts created by the API Broadcasts created by the API are different in that: - they aren’t created by any user, so don’t have a `created_by_id` - they are created instantly, not in steps, so don’t have an `updated_at` time This commit alters the views to account for when these pieces of information aren’t present.
2021-01-27 11:24:22 +00:00
{% if broadcast_message.count_of_phones == 0 %}
Unknown number of phones
{% elif broadcast_message.count_of_phones == broadcast_message.count_of_phones_likely %}
Make estimated phone count clearer We’ve had some feedback from user research that difference between ‘will get alert’ and ‘likely to get alert’ is not clear, and it’s hard to tell if the latter is inclusive of the former. This leads people to question the validity of these numbers, which is important, because an the estimate should give you some idea of the impact of what you’re about to do. This commit reformats the number as a range, for example 1,000 to 2,000 phones. If the range is small, eg 40,000,000 to 40,800,000 then this suggests a false level of accuracy. So instead we just give one number and say it’s an estimate, eg ‘40,000,000 phones estimated’
2020-09-24 15:52:18 +01:00
{{ broadcast_message.count_of_phones|format_thousands }} phones estimated
{% else %}
{{ broadcast_message.count_of_phones|format_thousands }} to {{ broadcast_message.count_of_phones_likely|format_thousands }} phones
{% endif %}
Change map key items from list to paragraphs I recently found that there is a problem with the overuse of lists online for sequences of content that don't need to be in a list. I think that's what we're doing with our map key. The problem is large enough that browsers include heuristics to determine if lists should be presented as such to the accessibility API (and so to assistive tech' like screen readers). This thread contains more details: https://twitter.com/cookiecrook/status/1337226933822603270 Based on the metric described in the thread: 'If all of the styles that make it “list-like” have been removed, it’s no longer relevant to convey it as a list.' ...or 'if a sighted user doesn’t need to know it’s a list, why would a screen reader user need to know or want to know?' Based on that, I think the items in our map key should be paragraphs, not items in a list. Also, they read really well as sentences when announced by a screen reader, partly because of the extra (hidden) info @quis added to them. This also doesn't change their visual appearance.
2021-10-07 14:29:51 +01:00
</p>
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
{% endmacro %}
Reference in New Issue Copy Permalink