michaeldera / image-accessibility-extension Goto Github PK

Is your feature request related to a problem? Please describe.
At the moment the api is open but it will need to be closed if there is mass usage in case the endpoint to the api is used for purposes other than to support this extension. So the extension must have a key it uses to authenticate with the API to be granted access.

Describe the solution you'd like
A key tied to the extension (preferred) or accounts for the users

Describe alternatives you've considered
Rate-limiting from the API end.

Describe the bug
Right now everything works just well, when Image a11y processes the page on initial load. However, when content is loaded or changes dynamically, the alt labels are not updated. This leads to scenario where 'apples' are still labelled as 'oranges'.

To Reproduce
Steps to reproduce the behavior:

1. Download this gist https://gist.github.com/nadchif/211ecfab904d53880fb8e021c44c7f0b
2. Serve on localhost with Image a11y enabled

Expected behavior
Detect image src and DOM changes in order to update the alt labels dynamically

Desktop (please complete the following information):

• Browser Chrome
• Version 81

Right now, if https://soure/of/image.jpg is used (without an alt attribute) in page1.html, Image a11y will query the server for a description. If the user navigates to page2.html, and https://soure/of/image.jpg is also used there, Image a11y will again query the server for description.

Describe the solution you'd like
Image a11y could have a service-worker that intercepts fetch requests and caches responses. (Read more...). If requests to the same image source are made within a certain time frame, the service-worker can just return the cached response.

Additional context
There may be a set back on images dynamically served by the server. For example, if a server returns an apple from <img src="https://soure/of/generate-random-fruit">, and on the next request the the same https://soure/of/generate-random-fruit results in an orange being returned from the server.

Describe the bug
When you load the "classic" php pages that don't use "pretty" urls, the modified url for the images with a relative src is incorrect.

To Reproduce
Steps to reproduce the behavior:

1. Go to a site that ends with a page + extension, like index.html or index.php that uses relative url for an image.
2. Image a11y will now use the following fetch url https://image-recognition-function.azurewebsites.net/api/AnalyseImage?url=http://www.site.com/index.php/images/image.jpg
3. See the following error from the API:

{"code":"InvalidImageUrl","requestId":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx","message":"Image URL is not accessible."}

Expected behavior
Image a11y should use the following url https://image-recognition-function.azurewebsites.net/api/AnalyseImage?url=http://www.site.com/images/image.jpg to request description from API.

Desktop (please complete the following information):

• Browser Chrome
• Version 81

Additional context
i think a regex test against window.location.pathname, while determining the src variable in src/add-alt-attributes.js could be a way to resolve this

Describe the bug
When I call the REST endpoint that is supposed to receive the JSON payload with the content of the image, I get a Readable Stream object in the response body (response.body), I am not having the best time trying to read the stream.

To Reproduce
Steps to reproduce the behavior:

1. Clone the repo and and set up the extension in developer mode as inidcated in the contributing guidelines
2. Active the extension and add a debugger (debugger;) on the response from fetch;
3. Inspection of the response.body after reloading a page with an image without alt atttributes will indicate it is a readable stream

Expected behavior
Would like to either be able to read the stream or to receive the response as a JSON payload (Worth mentioning that tools such as Swagger, Insomnia, Postman receive the reponse as JSON)

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Microsoft Edge (Chromium)
• Version 81.0.416.68 (Official build) (64-bit)

Is your feature request related to a problem? Please describe.
The extension at the moment will simply set the alt attribute even if the image recognition api has low confidence value in the caption. What's worse if that the user currently has no way of knowing that the caption may not be what is described.

Describe the solution you'd like
A way for users to either specify the level of confidence they want for their images (for example: alt attributes are only added for images with confidence of greater than 75%)

or

Each alt attribute is assigned with the value of confidence the extension has in the image... these need not be numbers as that may not be nice to listen to.... it may be key phrases like ("likely to be" for mid confidence images and another like "may be" for low confidence images.

Describe alternatives you've considered
Another alternative is to provide more than one caption in the alt attribute by say "or it may be" as a concatenation. These should ideally be options.

Additional context
The api returns a payload with different possible captions... but sometimes all the captions are low confidence captions.