How to deal with small extra touches needed in order to close a task

Scrum isn't ticket based, it's commitment based. At least one Product Increment must be Done, and of immediate usable quality, which proves that a Sprint Goal has been satisfied.

Was the work you have described sufficiently refined and ready for Sprint Planning? In Scrum, a "ready" state means that the Developers know the work can be Done in a Sprint, and so will not be unduly surprised by the things they have to do.

What does the Definition of Done say?

The first place that I'd look is the Definition of Done. In this specific example, the concern seems to be around the UI look and feel. I would expect the Definition of Done to include a reference to any design standards or design systems that the organization has in place. If this new color scheme is a violation of those standards, then the work isn't done since it doesn't meet the Definition of Done. If you don't have design standards or a design system in place, then perhaps this issue is revealing a weakness that can be looked at.

What does the Product Owner say?

The Product Owner is accountable for the value of their product and represents the many stakeholders who have an interest in the product. The Product Owner can weigh in on if the solution, as designed and implemented, meets the needs of the stakeholders. A solution that is unacceptable to stakeholders would likely need to be reworked. The Product Owner can decide if it's better to deliver what has been done because it's an improvement over the previous state or if the work is unacceptable for delivery.

Getting into how you manage undone or unacceptable work is a very different question, and one that is unique to each team. In this case, it depends on if you deliver the work as-is or not. If you decide that the work is not done, then I would prefer a solution where you move your work card back to a state that represents the work until it is fully finished. However, if you decide to ship the work and revisit it later, I would expect a new work card to be added to the Product Backlog, refined, and ordered among all the other possible options for work.

Hello!
So i am presenting the following situation: (fictional or not, it is just for example)
A ticket regarding the functionality of a scrollbar is raised (it was missing, malfunctioning from time to time). No specifications regarding the design were mentioned, thinking of the Dev will either follow the product's design scheme or ask for opinion when developing (to be mentioned that is a small team where Devs and QA are in constant touch... so things are also made off the records sometimes).

The Dev fixed the functionality and also implemented a new color scheme to the scrollbars; color scheme that i have marked as inappropriate (a burst of strong color for a Dark theme).
And now comes the question:

1. Mark the ticket as Passed / Done ... due to the fact that the specifications from the ticket are met and then submit a new ticket regarding the color scheme?
2. Leave a comment and Fail/Reopen (depending how the Jira Workflow is designed), mentioning that the color scheme is not a proper one and change with new colors (even providing the color codes) ?

Discussion:

For scenario 1:

Personally, i don't like to close as Done this kind of tickets. I'd rather fail/reopen the issue if the needed fix is just a quick touch of CSS.

We talk about "extra" work related to minutes.. not hours.

Closing that issue as Done and submitting a new one means:
- spending time submitting a new issue 
- the issue will be send to the backlog (depending to the Sprint planning strategy, it may be left there at least until the next Sprint planning)
- during the next (hopefully) Sprint planning, the issue will be discussed, estimated, assigned, insert in the Sprint
- time passed until the ticket is reached by the Dev
- the tickets joins the workflow To do -> In progress Dev -> Dev Done -> Stagging -> Ready for QA -> QA Status...

All this time wasted for changing a color code. 
 

For scenario 2:

The way i prefer to work, but to mention that i choose this only when the "extra" work is about minute(s) of work, not hours (changing color codes, radius, borders, position, a typo .. quick CSS editing in 99% of time).
By doing this i make sure that the job is done with priority, as we want to close the ticket asap.
And personally, i want to know that i leave that area under work in a DONE state and forget about it. I don't want to come back in 1-2-3-10-20 days just to check that colors. Havin that scrollbars with a bad color scheme until the next Sprint (at least) is not the thing i want.

Your Definition of Done should have some bearing in this. As @Thomas stated, if there are any corporate design standards stated, the Definition of Done should state that all work has to meet those standards.  If none exist (which I find hard to believe in today's environments) then it might be time to get some created and use this example as the reason. 

As @Ian states, Scrum really doesn't care how "tickets" are handled and doesn't even advocate that they are used.  It is focused on Product Backlog Items and the focus of getting them to a usable, valuable state that is delivered to the stakeholders. How your organization chooses to do that is not a Scrum concern.  I've used spreadsheets, sticky notes, multiple applications and even email to manage the Product Backlog Items.  They all worked for the organization, situation and team.