{"version":"https:\/\/jsonfeed.org\/version\/1","title":{"value":"yatil.net feed"},"home_page_url":"https:\/\/yatil.net","feed_url":"https:\/\/yatil.net\/blog","items":[{"id":"https:\/\/yatil.net\/blog\/aria-serious-at-technica11y","url":"https:\/\/yatil.net\/blog\/aria-serious-at-technica11y","title":"ARIA Serious ?! @ technica11y","content_html":"

It is an updated talk from the one I gave several times before but it is always nice to document new and inventive atrocities.<\/p>\n

When:<\/strong> October 2, 2019, 11am ET<\/a>
\nWhere:<\/strong> Online,
Register here<\/a><\/p>","date_published":"2019-09-29T15:00:00+02:00","date_modified":"2019-09-29T15:20:17+02:00"},{"id":"https:\/\/yatil.net\/blog\/connecting-the-accessibility-dots-workshop-in-berlin-in-november","url":"https:\/\/yatil.net\/blog\/connecting-the-accessibility-dots-workshop-in-berlin-in-november","title":"Connecting the Accessibility Dots (Workshop in Berlin in November)","content_html":"

In this new workshop I want to help people wo have an understanding of specific parts of accessibility to get a better understanding on where this fits in the general framework of designing, writing, and developing accessible websites. The learning outcome should be a holistic approach to accessibility that leads participants to anticipate accessibility-related issues earlier.<\/p>\n

We look at the requirements for accessibility, the needs of people with disabilities, and how assistive technologies work. We\u2019ll answer the important questions about accessibility: Why is it important? What are the important concepts? How do people with disabilities actually use the web? How can we create accessible websites without consulting WCAG at every step? When, and how, can we make sure that we don\u2019t step into the same traps all the time again and again?<\/p>\n

In the second half of the workshop I\u2019ll then answer the specific questions of the audience (provided in advance), applying the approaches learned in the morning to practical use.<\/p>\n

When:<\/strong> November 17, 2019 (with Accessibility Club Summit Barcamp on Nov 16 and after beyondTellerrand, Nov 14 & 15)
\nWhere:<\/strong> To be determined, Berlin<\/p>\n

Buy tickets for the workshop at accessibility-club.org!<\/a><\/p>","date_published":"2019-09-29T12:30:00+02:00","date_modified":"2019-09-29T16:49:41+02:00"},{"id":"https:\/\/yatil.net\/blog\/open-in-overcast-bookmarklet","url":"https:\/\/yatil.net\/blog\/open-in-overcast-bookmarklet","title":"Open in Overcast Bookmarklet","content_html":"

Unfortunately there often is no link to the Overcast URL directly on the page despite Overcast having decent web integration1<\/a><\/sup>. Adding a podcast to Overcast in this case means copying the title of the podcast, open the web interface or the app, searching for the podcast, searching for the episode to sample. and adding this episode.<\/p>\n

It\u2019s not the end of the world, but it introduces some friction that seemed unnecessary to me.<\/p>\n

Overcast accesses the iTunes<\/del> Apple Podcast Directory and its podcast URLs take the same ID as is present in that directory. Due to the nature of Apple Podcasts, every podcast has a link to their entry on the page.<\/p>\n

JavaScript to the rescue!<\/strong><\/p>\n

I have created the following JavaScript2<\/a><\/sup> which searches for podcast links (two variations). If one is found, it extracts the ID using a regular expression, adds it to the Overcast URL and opens the URL in the current window\/tab.<\/p>\n

const regex = \/podcast\\\/id([0-9]*)\/i;\nvar itunes = document.querySelector('a[href^=\"https:\/\/itunes.apple.com\/\"][href*=\"\/podcast\/\"],a[href^=\"https:\/\/podcasts.apple.com\/\"]');\n\nif (itunes) {\n  var itunesid = regex.exec(itunes.getAttribute('href'));\n  var overcasturl = 'https:\/\/overcast.fm\/itunes' + itunesid[1];\n  window.location.href = overcasturl;\n} else {\n  alert('No Apple Podcasts link found. \ud83d\ude2d');\n}<\/code><\/pre>\n

I then used Peter Coles<\/a>\u2019 Bookmarklet Creator<\/a> to generate a bookmarklet.<\/p>\n

To install the bookmarklet, drag the following link to your bookmarks\/favorites bar:<\/p>\n

Open in Overcast<\/a><\/strong><\/p>\n

While searching for the episode and to add is still needed, I hope to try out to more diverse podcasts this way.<\/p>\n

  1. \n

    Which is one reason I switched back to Overcast twice after extended stints of trying out Castro where I prefer how podcast playlists are managed. ↩<\/a><\/p>\n<\/li>\n

  2. \n

    Not really rocket science. ↩<\/a><\/p>\n<\/li>\n<\/ol>\n<\/div>","date_published":"2019-08-27T15:20:00+02:00","date_modified":"2019-09-21T20:25:33+02:00"},{"id":"https:\/\/yatil.net\/blog\/accessible-css-generated-content","url":"https:\/\/yatil.net\/blog\/accessible-css-generated-content","title":"Accessible CSS Generated Content","content_html":"

    His1<\/a><\/sup> goal was to provide text effects by layering different styles of the same font on top of each other. Designers use this technique to extend a base font style with other flourishes of the same font. The final code he came up with is this HTML, using the notranslate<\/code> class to prevent translation of the heading2<\/a><\/sup>:<\/p>\n

    <h1 class=\"type-family-jakob notranslate\" \n    data-heading=\"France-Norv\u00e8ge\">\n      France-Norv\u00e8ge\n<\/h1><\/code><\/pre>\n

    The CSS looks like this:<\/p>\n

    [class*=\"type-family\"] { position: relative; }\n\n[class*=\"type-family\"]:before, [class*=\"type-family\"]:after {\n  content: attr(data-heading);\n  position: absolute;\n  z-index: 1;\n  overflow: hidden;\n  left: 0;\n  top: 0;\n  font-size: inherit;\n  font-weight: normal;\n}<\/code><\/pre>\n

    Until a couple of years ago, the browsers did not treat generated content as \u201creal\u201d content. They did not expose it to assistive technologies like screen readers. That created an issue, for example when web developers used CSS to specify the file format of a document:<\/p>\n

    <a href=\"link\/to\/an\/interesting.pdf\">\n  Get the Report\n<\/a><\/code><\/pre>\n
    a[href$=\"pdf\"]:after { content: \" (PDF)\"; }<\/code><\/pre>\n

    For visual users, the link text \u201cGet the Report (PDF)\u201d would have been clear. But \u201c(PDF)\u201d was not conveyed to screen readers and other assistive technologies and thus not their users. Most developers don\u2019t intend that behavior, so browsers started to treat generated content as actual content<\/em>.<\/p>\n

    Back to Andy\u2019s example. The \u201caccessible name\u201d (the label that assistive technology uses) of his heading rank 1 would include the :before<\/code> and the :after<\/code> version of the contentand the content of the <h1><\/code> itself. The browser \u201csees\u201d:<\/p>\n

    <h1 class=\"type-family-jakob notranslate\">\n  France-Norv\u00e8ge France-Norv\u00e8ge France-Norv\u00e8ge\n<\/h1><\/code><\/pre>\n

    There is an ARIA attribute that we can use to overwrite<\/em>3<\/a><\/sup> the content of the <h1><\/code>: aria-label<\/code>. So we could augment Andy\u2019s code like this to avoid tripling the heading:<\/p>\n

    <h1 class=\"type-family-jakob notranslate\" \n    data-heading=\"France-Norv\u00e8ge\"\n    aria-label=\"France-Norv\u00e8ge\">\n      France-Norv\u00e8ge\n<\/h1><\/code><\/pre>\n

    This would work, but having two attributes repeating the content of the heading feels wrong. As attr()<\/code> can use any attribute, not only data-<\/code> attributes4<\/a><\/sup>, we can use it with the aria-label<\/code> and remove data-heading<\/code>:<\/p>\n

    <h1 class=\"type-family-jakob notranslate\" \n    aria-label=\"France-Norv\u00e8ge\">\n      France-Norv\u00e8ge\n<\/h1><\/code><\/pre>\n
    [class*=\"type-family\"]:before, [class*=\"type-family\"]:after {\n  content: attr(aria-label);\n  \u2026\n}<\/code><\/pre>\n

    This is where this story could end. And indeed this is where this story would have ended a couple of weeks ago. Yet, thanks to accessibility advocates, aria-label<\/code> is now actually one of the attributes that is<\/em> translated when using Google Translate through Google Chrome<\/a> \u2013 but not in other browsers. If that is enough to remove the notranslate<\/code> class from the heading depends on your circumstances. As the short clip of this example codepen<\/a> shows, the aria-label<\/code> attribute translates nicely:<\/p>\n