I'm familiar with some Accessibility (WCAG) concepts and now I'm working to make our Components library fully accessible.
We use Angular and we're building lots of configurable Applications with those components.
When using the components, many people don't provide proper semantics such as alt for images, or aria-label for empty links or actions.
So, I'm going through most of our components and optimizing those, so I can dynamically extract information from the component by using InnerHTML or similar approaches and then dynamically setting properties such as alt or aria-label through Angular.
What do you think about this? Is this a good idea? Will this be too bad for the performance of those components in heavy views?
I'd be glad to hear your opinion on this.
An example: We have a placeholder component, that we always provide a placeholderTitle but not alt for the images. So, in theory I would say, get the innerText of placeholderTitle and set it on placeholderImage.alt.
P.S. This approach is already enabling me to relatively easily reach 100% Accessibility in Google Lighthouse audit, and things such as Keyboard Interactions are being manually tested.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
More than happy to have a look at it for you and thank you for breaking the silence on my AMA! 🙂
Using .innerHTML should be performant unless you are inserting war and peace, but if you have a Content Security Policy with require-trusted-types-for 'script' you will have to sanitise it (I can tell you more about that if that is a problem for you, but most sites don't use that yet) or it will get blocked.
Also it is always better to try and use createDocumentFragment or a similar "Angular style" technique of building the element outside the DOM if you are building anything complex, just to avoid unnecessary updates and repaints on slower devices.
Do you want to put some HTML down that explains the placeholder component more clearly so I understand the purpose and how it is structured. In principle the answer is "yes, move the title onto the image as an alt attribute as title is not accessible but I might be misunderstanding what your component does / looks like.
General quick starting place for catching empty alt attributes etc.
As I can't quite help with the placeholder thing yet, I thought I would share a general trick for missing alt attributes etc.
I put together "development style sheets" that flag certain things and might be something you could implement as a quick fix while you work on automating as much as you can.
For example images with an empty alt attribute can easily be flagged up with the following CSS:
Or if you want to really annoy people into putting alt attributes in place you can even over-ride their pictures
The same principle can be used to pick up empty headings (h1:empty), lists that have children that are not <li> => :is(ul, ol) > *:not(li) { outline: 2px dotted red;} or my favourite, "the anchor antipattern finder":
There is no substitute for a piece of paper over the screen and learning to use a screen reader for finding accessibility issues.
Let's see some code 😁
Feel free to put a couple of minimal fiddles together for your placeholder component and for the innerHTML approach for setting aria-label (as need to see that too to understand what you are adding to an aria-label) and I will help you refine them / point out any "gotchyas" that you might run in to!
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Hi Graham, thanks for this opportunity.
I'm familiar with some Accessibility (WCAG) concepts and now I'm working to make our Components library fully accessible.
We use Angular and we're building lots of configurable Applications with those components.
When using the components, many people don't provide proper semantics such as
altfor images, oraria-labelfor empty links or actions.So, I'm going through most of our components and optimizing those, so I can dynamically extract information from the component by using InnerHTML or similar approaches and then dynamically setting properties such as
altoraria-labelthrough Angular.What do you think about this? Is this a good idea? Will this be too bad for the performance of those components in heavy views?
I'd be glad to hear your opinion on this.
An example: We have a placeholder component, that we always provide a
placeholderTitlebut notaltfor the images. So, in theory I would say, get theinnerTextofplaceholderTitleand set it onplaceholderImage.alt.P.S. This approach is already enabling me to relatively easily reach 100% Accessibility in Google Lighthouse audit, and things such as Keyboard Interactions are being manually tested.
Hi Ardian
More than happy to have a look at it for you and thank you for breaking the silence on my AMA! 🙂
Using
.innerHTMLshould be performant unless you are inserting war and peace, but if you have a Content Security Policy with require-trusted-types-for 'script' you will have to sanitise it (I can tell you more about that if that is a problem for you, but most sites don't use that yet) or it will get blocked.Also it is always better to try and use createDocumentFragment or a similar "Angular style" technique of building the element outside the DOM if you are building anything complex, just to avoid unnecessary updates and repaints on slower devices.
Do you want to put some HTML down that explains the placeholder component more clearly so I understand the purpose and how it is structured. In principle the answer is "yes, move the
titleonto the image as analtattribute astitleis not accessible but I might be misunderstanding what your component does / looks like.General quick starting place for catching empty
altattributes etc.As I can't quite help with the placeholder thing yet, I thought I would share a general trick for missing
altattributes etc.I put together "development style sheets" that flag certain things and might be something you could implement as a quick fix while you work on automating as much as you can.
For example images with an empty
altattribute can easily be flagged up with the following CSS:Or if you want to really annoy people into putting alt attributes in place you can even over-ride their pictures
The same principle can be used to pick up empty headings (
h1:empty), lists that have children that are not<li>=>:is(ul, ol) > *:not(li) { outline: 2px dotted red;}or my favourite, "the anchor antipattern finder":thank you I think I may have just found at least one post topic to write about!
Beware the automated audit trap!
Automatic audits are great to pick simple things up, but they only cover 35-45% of errors at most.
There is no substitute for a piece of paper over the screen and learning to use a screen reader for finding accessibility issues.
Let's see some code 😁
Feel free to put a couple of minimal fiddles together for your placeholder component and for the
innerHTMLapproach for settingaria-label(as need to see that too to understand what you are adding to anaria-label) and I will help you refine them / point out any "gotchyas" that you might run in to!Just wondered if you still needed help with this bud? Drop me a fiddle if you do and I will look at it for you.